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Introduction to Oracle SQL 


Structured Query Language (SQL) is the set of statements with which all 
programs and users access data in an Oracle Database. Application 
programs and Oracle tools often allow users access to the database without 
using SQL directly, but these applications in turn must use SQL when 
executing the user's request. 


History of SQL 


Dr. E. F. Codd published the paper, "A Relational Model of Data for Large 
Shared Data Banks", in June 1970 in the Association of Computer 
Machinery (ACM) journal, Communications of the ACM . Codd's model is 
now accepted as the definitive model for relational database management 
systems (RDBMS). The language, Structured English Query Language 
(SEQUEL) was developed by IBM Corporation, Inc., to use Codd's model. 
SEQUEL later became SQL (still pronounced "sequel"). In 1979, Relational 
Software, Inc. (now Oracle) introduced the first commercially available 
implementation of SQL. Today, SQL is accepted as the standard RDBMS 
language. 


How SQL Works 


The strengths of SQL provide benefits for all types of users, including 
application programmers, database administrators, managers, and end users. 
Technically speaking, SQL is a data sublanguage. The purpose of SQL is to 
provide an interface to a relational database such as Oracle Database, and 
all SQL statements are instructions to the database. In this SQL differs from 
general-purpose programming languages like C and BASIC. Among the 
features of SQL are the following: 


- It processes sets of data as groups rather than as individual units. 


It provides automatic navigation to the data. 


- It uses statements that are complex and powerful individually, and 
that therefore stand alone. 


SQL lets you work with data at the logical level. You need to be concerned 
with the implementation details only when you want to manipulate the data. 


For example, to retrieve a set of rows from a table, you define a condition 
used to filter the rows. All rows satisfying the condition are retrieved ina 
single step and can be passed as a unit to the user, to another SQL 
statement, or to an application. You need not deal with the rows one by one, 
nor do you have to worry about how they are physically stored or retrieved. 
All SQL statements use the optimizer , a part of Oracle Database that 
determines the most efficient means of accessing the specified data. Oracle 
also provides techniques that you can use to make the optimizer perform its 
job better. 


SQL provides statements for a variety of tasks, including: 
- Querying data 
- Inserting, updating, and deleting rows in a table 
- Creating, replacing, altering, and dropping objects 
- Controlling access to the database and its objects 
- Guaranteeing database consistency and integrity 


SQL unifies all of the preceding tasks in one consistent language. 
Common Language for All Relational Databases 


All major relational database management systems support SQL, so you can 
transfer all skills you have gained with SQL from one database to another. 
In addition, all programs written in SQL are portable. They can often be 
moved from one database to another with very little modification. 


Tools Support 


Oracle provides a number of utilities to facilitate your SQL development 
process: 


e Oracle SQL Developer is a graphical tool that lets you browse, 
create, edit, and delete (drop) database objects, edit and debug 
PL/SQL code, run SQL statements and scripts, manipulate and export 
data, and create and view reports. With SQL Developer, you can 
connect to any target Oracle Database schema using standard Oracle 
Database authentication. Once connected, you can perform operations 
on objects in the database. You can also connect to schemas for 
selected third-party (non-Oracle) databases, such as MySQL, 


Microsoft SQL Server, and Microsoft Access, view metadata and data 
in these databases, and migrate these databases to Oracle. 


SQL *Plus is an interactive and batch query tool that is installed with 
every Oracle Database server or client installation. It has a command- 
line user interface and a Web-based user interface called iSQL*Plus. 


Oracle JDeveloper is a multiple-platform integrated development 
environment supporting the complete lifecycle of development for 
Java, Web services, and SQL. It provides a graphical interface for 
executing and tuning SQL statements and a visual schema 
diagrammer (database modeler). It also supports editing, compiling, 
and debugging PL/SQL applications. 


Oracle Application Express is a hosted environment for developing 
and deploying database-related Web applications. SQL Workshop is a 
component of Oracle Application Express that lets you view and 
manage database objects from a Web browser. SQL Workshop offers 
quick access to a SQL command processor and a SQL script 
repository. 


Basic Elements of Oracle SQL 
The basic elements of Oracle SQL, these elements are the simplest building blocks of SQL statements. 


Data Types 
- Data Type Comparison Rules 
Literals 
Format Models 
e Nulls 
Comments 
Database Objects 
- Database Object Names and Qualifiers 


Syntax for Schema Objects and Parts in SQL Statements 


Data Types 


Each value manipulated by Oracle Database has a data type . The data type of a value associates a fixed set of 
properties with the value. These properties cause Oracle to treat values of one data type differently from values of 
another. For example, you can add values of NUMBER data type, but not values of RAW data type. 


When you create a table or cluster, you must specify a data type for each of its columns. When you create a 
procedure or stored function, you must specify a data type for each of its arguments. These data types define the 
domain of values that each column can contain or each argument can have. For example, DATE columns cannot 
accept the value February 29 (except for a leap year) or the values 2 or 'SHOE'. Each value subsequently placed in 
a column assumes the data type of the column. For example, if you insert '01-JAN-98' into a DATE column, then 
Oracle treats the '01-JAN-98' character string as a DATE value after verifying that it translates to a valid date. 


Oracle Database provides a number of built-in data types as well as several categories for user-defined types that 
can be used as data types. The syntax of Oracle data types appears in the diagrams that follow. The text of this 
section is divided into the following sections: 
e Oracle Built-in Data Types 
ANSI, DB2, and SQL/DS Data Types 
- User-Defined Types 
Oracle-Supplied Types 
Data Type Comparison Rules 
- Data Conversion 
A data type is either scalar or nonscalar. A scalar type contains an atomic value, whereas a nonscalar (sometimes 
called a "collection") contains a set of values. A large object (LOB) is a special form of scalar data type 
representing a large scalar value of binary or character data. LOBs are subject to some restrictions that do not 


affect other scalar types because of their size. Those restrictions are documented in the context of the relevant SQL 
syntax. 


Oracle Built-in Data Types 


The Built-In Data Type Summary table lists the built-in data types available. Oracle Database uses a code to 
identify the data type internally. This is the number in the Code column of the Built-In Data Type Summary 
table. You can verify the codes in the table using the DUMP function. 


In addition to the built-in data types listed in the Built-In Data Type Summary table, Oracle Database uses 
many data types internally that are visible via the DUMP function. 


Built-In Data Type Summary 


Code 


1 


12 


100 


101 


180 


Data Type 


VARCHAR2( size 
[BYTE | CHAR]) 


NVARCHAR2( size ) 


NUMBER [(p L s])] 


FLOAT [(p J] 


LONG 


DATE 


BINARY_FLOAT 
BINARY_DOUBLE 


TIMESTAMP [( 
fractional_seconds_precision 


)] 


Description 


Variable-length character string having maximum length size bytes or c 
You must specify size for VARCHAR2. Minimum size is 1 byte or 1 c 
Maximum size is: 


32767 bytes or characters if MAX_STRING_SIZE = EXTENDEL 
- 4000 bytes or characters if MAX_STRING_SIZE = STANDARD 


Variable-length Unicode character string having maximum length size < 
You must specify size for NVARCHAR2. The number of bytes can be t 
times size for ALI6UTF16 encoding and three times size for UTF8 en 
Maximum size is determined by the national character set definition, wi 
upper limit of: 


32767 bytes if MAX_STRING_SIZE = EXTENDED 
- 4000 bytes if MAX STRING_SIZE = STANDARD 


Number having precision p and scale s . The precision p can range frc 
38. The scale s can range from -84 to 127. Both precision and scale are 
decimal digits. A NUMBER value requires from 1 to 22 bytes. 


A subtype of the NUMBER data type having precision p . A FLOAT val 
represented internally as NUMBER. The precision p can range from 1 t 
binary digits. A FLOAT value requires from 1 to 22 bytes. 


Character data of variable length up to 2 gigabytes, or 2 *' -1 bytes. Prov 
backward compatibility. 


Valid date range from January 1, 4712 BC, to December 31, 9999 AD. T 
format is determined explicitly by the NLS_DATE_FORMAT parameter 
implicitly by the NLS_TERRITORY parameter. The size is fixed at 7 by 
data type contains the datetime fields YEAR, MONTH, DAY, HOUR, M 
and SECOND. It does not have fractional seconds or a time zone. 


32-bit floating point number. This data type requires 4 bytes. 
64-bit floating point number. This data type requires 8 bytes. 


Year, month, and day values of date, as well as hour, minute, and second 
time, where fractional_seconds_precision is the number of digits in the 
part of the SECOND datetime field. Accepted values of 
fractional_seconds_precision are 0 to 9. The default is 6. The default fo 
determined explicitly by the NLS_TIMESTAMP_FORMAT parameter o 
implicitly by the NLS_TERRITORY parameter. The size is 7 or 11 bytes 
depending on the precision. This data type contains the datetime 

fields YEAR, MONTH, DAY, HOUR, MINUTE, and SECOND. It conte 
fractional seconds but does not have a time zone. 


Code 


181 


231 


182 


183 


23 


24 


69 


208 


96 


Data Type 


TIMESTAMP [( 
fractional_seconds_precision 
)] WITH TIME ZONE 


TIMESTAMP [( 
fractional_seconds_precision 
)] WITH LOCAL TIME ZONE 


INTERVAL YEAR [( 
year_precision )] TO MONTH 


INTERVAL DAY [( 
day_precision 

)] TO SECOND [( 
fractional_seconds_precision 


)] 


RAW ( size ) 


LONG RAW 


ROWID 


UROWID [( size )] 


CHAR [( size 
[BYTE | CHAR])] 


Description 


All values of TIMESTAMP as well as time zone displacement value, wh 
fractional_seconds_precision is the number of digits in the fractional pa 
the SECOND datetime field. Accepted values are 0 to 9. The default is 6 
default date format for the TIMESTAMP WITH TIME ZONE data type 
determined by the NLS_TIMESTAMP_TZ_FORMAT initialization para 
The size is fixed at 13 bytes. This data type contains the datetime 

fields YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, TIMEZON 
and TIMEZONE_MINUTE. It has fractional seconds and an explicit tim 


All values of TIMESTAMP WITH TIME ZONE, with the following exc 
Data is normalized to the database time zone when it is stored in tl 
database. 

- When the data is retrieved, users see the data in the session time zc 

The default format is determined explicitly by 

the NLS_TIMESTAMP_FORMAT parameter or implicitly by 


the NLS_TERRITORY parameter. The size is 7 or 11 bytes, depending o 
precision. 


Stores a period of time in years and months, where year_precision is th 
of digits in the YEAR datetime field. Accepted values are 0 to 9. The del 
The size is fixed at 5 bytes. 


Stores a period of time in days, hours, minutes, and seconds, where 


day_precision is the maximum number of digits in the DAY dateti 
Accepted values are 0 to 9. The default is 2. 


fractional_seconds_precision is the number of digits in the fractio 
the SECOND field. Accepted values are 0 to 9. The default is 6. 


The size is fixed at 11 bytes. 
Raw binary data of length size bytes. You must specify size fora RAW 
Maximum size is: 


32767 bytes if MAX_STRING_SIZE = EXTENDED 
2000 bytes if MAX_STRING_SIZE = STANDARD 


Raw binary data of variable length up to 2 gigabytes. 


Base 64 string representing the unique address of a row in its table. This 
is primarily for values returned by the ROWID pseudocolumn. 


Base 64 string representing the logical address of a row of an index-orga 
table. The optional size is the size of a column of type UROWID. The r 
size and default is 4000 bytes. 


Fixed-length character data of length size bytes or characters. Maximun 
2000 bytes or characters. Default and minimum size is 1 byte. 


BYTE and CHAR have the same semantics as for VARCHAR2. 


Code Data Type Description 


96 NCHARI[( size )] Fixed-length character data of length size characters. The number of by 
up to two times size for ALI16UTF16 encoding and three times size 
for UTF8 encoding. Maximum size is determined by the national chara 
definition, with an upper limit of 2000 bytes. Default and minimum size 
character. 


112 CLOB A character large object containing single-byte or multibyte characters. E 
fixed-width and variable-width character sets are supported, both using t 
database character set. Maximum size is (4 gigabytes - 1) * (database blc 


112 NCLOB A character large object containing Unicode characters. Both fixed-widtl 
variable-width character sets are supported, both using the database natic 
character set. Maximum size is (4 gigabytes - 1) * (database block size). 
national character set data. 


113 BLOB A binary large object. Maximum size is (4 gigabytes - 1) * (database blo 

114 BFILE Contains a locator to a large binary file stored outside the database. Enak 
stream I/O access to external LOBs residing on the database server. Max 
is 4 gigabytes. 


Character Data Types 


Character data types store character (alphanumeric) data, which are words and free-form text, in the database 
character set or national character set. They are less restrictive than other data types and consequently have fewer 
properties. For example, character columns can store all alphanumeric values, but NUMBER columns can store 
only numeric values. 


Character data is stored in strings with byte values corresponding to one of the character sets, such as 7-bit ASCII 
or EBCDIC, specified when the database was created. Oracle Database supports both single-byte and multibyte 
character sets. 


These data types are used for character data: 


CHAR Data Type 

- NCHAR Data Type 
VARCHAR2 Data Type 

e NVARCHAR2 Data Type 


CHAR Data Type 


The CHAR data type specifies a fixed-length character string in the database character set. You specify the 
database character set when you create your database. 


When you create a table with a CHAR column, you specify the column length as size optionally followed by a 
length qualifier. The qualifier BYTE denotes byte length semantics while the qualifier CHAR denotes character 
length semantics. In the byte length semantics, size is the number of bytes to store in the column. In the character 
length semantics, size is the number of code points in the database character set to store in the column. A code 
point may have from 1 to 4 bytes depending on the database character set and the particular character encoded by 
the code point. Oracle recommends that you specify one of the length qualifiers to explicitly document the desired 
length semantics of the column. If you do not specify a qualifier, the value of 

the NLS_LENGTH_SEMANTICS parameter of the session creating the column defines the length semantics, 
unless the table belongs to the schema SYS, in which case the default semantics is BYTE. 


Oracle ensures that all values stored ina CHAR column have the length specified by size in the selected length 
semantics. If you insert a value that is shorter than the column length, then Oracle blank-pads the value to column 
length. If you try to insert a value that is too long for the column, then Oracle returns an error. Note that if the 
column length is expressed in characters (code points), blank-padding does not guarantee that all column values 
have the same byte length. 


You can omit size from the column definition. The default value is 1. 


The maximum value of size is 2000, which means 2000 bytes or characters (code points), depending on the 
selected length semantics. However, independently, the absolute maximum length of any character value that can 
be stored into a CHAR column is 2000 bytes. For example, even if you define the column length to be 2000 
characters, Oracle returns an error if you try to insert a 2000-character value in which one or more code points are 
wider than 1 byte. The value of size in characters is a length constraint, not guaranteed capacity. If you want 

a CHAR column to be always able to store size characters in any database character set, use a value of size that 
is less than or equal to 500. 


To ensure proper data conversion between databases and clients with different character sets, you must ensure 
that CHAR data consists of well-formed strings. 


NCHAR Data Type 


The NCHAR data type specifies a fixed-length character string in the national character set. You specify the 
national character set as either AL16UTF16 or UTF8 when you create your database. ALI6UTF16 and UTF8 are 
two encoding forms of the Unicode character set (UTF-16 and CESU-8, correspondingly) and hence NCHAR is a 
Unicode-only data type. 


When you create a table with an NCHAR column, you specify the column length as size characters, or more 
precisely, code points in the national character set. One code point has always 2 bytes in ALI6UTF16 and from 1 
to 3 bytes in UTF8, depending on the particular character encoded by the code point. 


Oracle ensures that all values stored in an NCHAR column have the length of size characters. If you insert a value 
that is shorter than the column length, then Oracle blank-pads the value to the column length. If you try to insert a 
value that is too long for the column, then Oracle returns an error. Note that if the national character set is UTF8, 
blank-padding does not guarantee that all column values have the same byte length. 


You can omit size from the column definition. The default value is 1. 


The maximum value of size is 1000 characters when the national character set is ALI6UTF16, and 2000 
characters when the national character set is UTF8. However, independently, the absolute maximum length of any 
character value that can be stored into an NCHAR column is 2000 bytes. For example, even if you define the 
column length to be 1000 characters, Oracle returns an error if you try to insert a 1000-character value but the 
national character set is UTF8 and all code points are 3 bytes wide. The value of size is a length constraint, not 
guaranteed capacity. If you want an NCHAR column to be always able to store size characters in both national 
character sets, use a value of size that is less than or equal to 666. 


To ensure proper data conversion between databases and clients with different character sets, you must ensure 
that NCHAR data consists of well-formed strings. 


If you assign a CHAR value to an NCHAR column, the value is implicitly converted from the database character 
set to the national character set. If you assign an NCHAR value to a CHAR column, the value is implicitly 
converted from the national character set to the database character set. If some of the characters from 

the NCHAR value cannot be represented in the database character set, then if the value of the session 

parameter NLS_NCHAR_CONV_EXCP is TRUE, then Oracle reports an error. If the value of the parameter 

is FALSE, non-representable characters are replaced with the default replacement character of the database 
character set, which is usually the question mark '?' or the inverted question mark '¿'. 


VARCHAR? Data Type 


The VARCHAR2 data type specifies a variable-length character string in the database character set. You specify 
the database character set when you create your database. 


When you create a table with a VARCHAR2 column, you must specify the column length as size optionally 
followed by a length qualifier. The qualifier BYTE denotes byte length semantics while the 

qualifier CHAR denotes character length semantics. In the byte length semantics, size is the maximum number of 
bytes that can be stored in the column. In the character length semantics, size is the maximum number of code 
points in the database character set that can be stored in the column. A code point may have from 1 to 4 bytes 
depending on the database character set and the particular character encoded by the code point. Oracle 
recommends that you specify one of the length qualifiers to explicitly document the desired length semantics of the 
column. If you do not specify a qualifier, the value of the NLS_LENGTH_SEMANTICS parameter of the session 
creating the column defines the length semantics, unless the table belongs to the schema SYS, in which case the 
default semantics is BYTE. 


Oracle stores a character value ina VARCHAR2 column exactly as you specify it, without any blank-padding, 
provided the value does not exceed the length of the column. If you try to insert a value that exceeds the specified 
length, then Oracle returns an error. 


The minimum value of size is 1. The maximum value is: 


32767 bytes if MAX _STRING_SIZE = EXTENDED 
- 4000 bytes if MAX _STRING_SIZE = STANDARD 


While size may be expressed in bytes or characters (code points) the independent absolute maximum length of 
any character value that can be stored into a VARCHAR2 column is 32767 or 4000 bytes, depending 

on MAX_STRING_SIZE. For example, even if you define the column length to be 32767 characters, Oracle 
returns an error if you try to insert a 32767-character value in which one or more code points are wider than 1 byte. 
The value of size in characters is a length constraint, not guaranteed capacity. If you want a VARCHAR2 column 
to be always able to store size characters in any database character set, use a value of size that is less than or 
equal to 8191, if MAX_STRING_SIZE = EXTENDED, or 1000, if MAX_STRING_SIZE = STANDARD. 


Oracle compares VARCHAR2 values using non-padded comparison semantics. 


To ensure proper data conversion between databases with different character sets, you must ensure 
that VARCHAR2 data consists of well-formed strings. 


VARCHAR Data Type 


Do not use the VARCHAR data type. Use the VARCHAR2 data type instead. Although the VARCHAR data type 
is currently synonymous with VARCHAR2, the VARCHAR data type is scheduled to be redefined as a separate 
data type used for variable-length character strings compared with different comparison semantics. 


NVARCHAR2 Data Type 


The NVARCHAR2 data type specifies a variable-length character string in the national character set. You specify 
the national character set as either ALI16UTF16 or UTF8 when you create your database. ALI6UTF16 and UTF8 
are two encoding forms of the Unicode character set (UTF-16 and CESU-8, correspondingly) and 

hence NVARCHAR2 is a Unicode-only data type. 


When you create a table with an NVARCHAR2 column, you must specify the column length as size characters, 
or more precisely, code points in the national character set. One code point has always 2 bytes in ALI6UTF16 and 
from 1 to 3 bytes in UTF8, depending on the particular character encoded by the code point. 


Oracle stores a character value in an NVARCHAR2 column exactly as you specify it, without any blank-padding, 
provided the value does not exceed the length of the column. If you try to insert a value that exceeds the specified 
length, then Oracle returns an error. 


The minimum value of size is 1. The maximum value is: 


16383 if MAX STRING_SIZE = EXTENDED and the national character set is ALIGUTF16 
e 32767 if MAX STRING_SIZE = EXTENDED and the national character set is UTF8 
2000 if MAX STRING_SIZE = STANDARD and the national character set is AL16UTF16 


4000 if MAX _STRING_SIZE = STANDARD and the national character set is UTF8 


Independently of the maximum column length in characters, the absolute maximum length of any value that can be 
stored into an NVARCHAR2 column is 32767 or 4000 bytes, depending on MAX_STRING_SIZE. For example, 
even if you define the column length to be 16383 characters, Oracle returns an error if you try to insert a 16383- 
character value but the national character set is UTF8 and all code points are 3 bytes wide. The value of size isa 
length constraint, not guaranteed capacity. If you want an NVARCHAR2 column to be always able to store size 
characters in both national character sets, use a value of size that is less than or equal to 10922, 

if MAX_STRING_SIZE = EXTENDED, or 1333, if MAX_STRING_SIZE = STANDARD. 


Oracle compares NVARCHAR2 values using non-padded comparison semantics. 


To ensure proper data conversion between databases and clients with different character sets, you must ensure 
that NVARCHAR2 data consists of well-formed strings. 


If you assign a VARCHAR2 value to an NVARCHAR2 column, the value is implicitly converted from the 
database character set to the national character set. If you assign an NVARCHAR2 value to 

a VARCHAR2 column, the value is implicitly converted from the national character set to the database character 
set. If some of the characters from the NVARCHAR2 value cannot be represented in the database character set, 
then if the value of the session parameter NLS_NCHAR_CONV_EXCP is TRUE, then Oracle reports an error. If 
the value of the parameter is FALSE, non-representable characters are replaced with the default replacement 
character of the database character set, which is usually the question mark '?' or the inverted question mark '¿'. 


Numeric Data Types 


The Oracle Database numeric data types store positive and negative fixed and floating-point numbers, zero, 
infinity, and values that are the undefined result of an operation—"not a number" or NAN. 


NUMBER Data Type 


The NUMBER data type stores zero as well as positive and negative fixed numbers with absolute values from 1.0 
x 10 * to but not including 1.0 x 10 '° . If you specify an arithmetic expression whose value has an absolute 
value greater than or equal to 1.0 x 10 *® , then Oracle returns an error. Each NUMBER value requires from 1 to 
22 bytes. 


Specify a fixed-point number using the following form: 


NUMBER(p,s) 


where: 


e p isthe precision, or the maximum number of significant decimal digits, where the most significant digit 
is the left-most nonzero digit, and the least significant digit is the right-most known digit. Oracle 
guarantees the portability of numbers with precision of up to 20 base-100 digits, which is equivalent to 39 
or 40 decimal digits depending on the position of the decimal point. 


s is the scale, or the number of digits from the decimal point to the least significant digit. The scale can 
range from -84 to 127. 
o Positive scale is the number of significant digits to the right of the decimal point to and including 
the least significant digit. 


o Negative scale is the number of significant digits to the left of the decimal point, to but not 
including the least significant digit. For negative scale the least significant digit is on the left side 
of the decimal point, because the actual data is rounded to the specified number of places to the 
left of the decimal point. For example, a specification of (10,-2) means to round to hundreds. 


Scale can be greater than precision, most commonly when e notation is used. When scale is greater than precision, 
the precision specifies the maximum number of significant digits to the right of the decimal point. For example, a 
column defined as NUMBER(4,5) requires a zero for the first digit after the decimal point and rounds all values 
past the fifth digit after the decimal point. 


It is good practice to specify the scale and precision of a fixed-point number column for extra integrity checking on 
input. Specifying scale and precision does not force all values to a fixed length. If a value exceeds the precision, 
then Oracle returns an error. If a value exceeds the scale, then Oracle rounds it. 


Specify an integer using the following form: 


NUMBER(p) 


This represents a fixed-point number with precision p and scale 0 and is equivalent to NUMBER(p,0). 


Specify a floating-point number using the following form: 


NUMBER 


The absence of precision and scale designators specifies the maximum range and precision for an Oracle number. 


Storage of Scale and Precision 


Actual Data Specified As Stored As 
123.89 NUMBER 123.89 
123.89 NUMBER(3) 124 
123.89 NUMBER(3,2) exceeds precision 
123.89 NUMBER(4,2) exceeds precision 
123.89 NUMBER(5,2) 123.89 
123.89 NUMBER(6,1) 123.9 
123.89 NUMBER(6,-2) 100 
.01234 NUMBER(4,5) .01234 
.00012 NUMBER(4,5) .00012 
.000127 NUMBER(4,5) .00013 
.0000012 NUMBER(2,7) .0000012 
.00000123 NUMBER(2,7) .0000012 
1.2e-4 NUMBER(2,5) 0.00012 
1.2e-5 NUMBER(2,5) 0.00001 
FLOAT Data Type 


The FLOAT data type is a subtype of NUMBER. It can be specified with or without precision, which has the same 
definition it has for NUMBER and can range from 1 to 126. Scale cannot be specified, but is interpreted from the 
data. Each FLOAT value requires from 1 to 22 bytes. 


To convert from binary to decimal precision, multiply n by 0.30103. To convert from decimal to binary precision, 
multiply the decimal precision by 3.32193. The maximum of 126 digits of binary precision is roughly equivalent to 
38 digits of decimal precision. 


The difference between NUMBER and FLOAT is best illustrated by example. In the following example the same 
values are inserted into NUMBER and FLOAT columns: 


CREATE TABLE test (coll NUMBER(5,2), col2 FLOAT(5)); 


INSERT INTO test VALUES (1.23, 1.23); 
INSERT INTO test VALUES (7.89, 7.89); 
INSERT INTO test VALUES (12.79, 12.79); 
INSERT INTO test VALUES (123.45, 123.45); 


SELECT * FROM test; 


COL1 COL2 
1.23 1.2 
7.89 7.9 
12.79 13 
123.45 120 


In this example, the FLOAT value returned cannot exceed 5 binary digits. The largest decimal number that can be 
represented by 5 binary digits is 31. The last row contains decimal values that exceed 31. Therefore, 

the FLOAT value must be truncated so that its significant digits do not require more than 5 binary digits. Thus 
123.45 is rounded to 120, which has only two significant decimal digits, requiring only 4 binary digits. 


Oracle Database uses the Oracle FLOAT data type internally when converting ANSI FLOAT data. 
Oracle FLOAT is available for you to use, but Oracle recommends that you use 
the BINARY_FLOAT and BINARY_DOUBLE data types instead, as they are more robust. 


Floating-Point Numbers 


Floating-point numbers can have a decimal point anywhere from the first to the last digit or can have no decimal 
point at all. An exponent may optionally be used following the number to increase the range, for example, 1.777 e 
° A scale value is not applicable to floating-point numbers, because the number of digits that can appear after the 
decimal point is not restricted. 


Binary floating-point numbers differ from NUMBER in the way the values are stored internally by Oracle 
Database. Values are stored using decimal precision for NUMBER. All literals that are within the range and 
precision supported by NUMBER are stored exactly as NUMBER. Literals are stored exactly because literals are 
expressed using decimal precision (the digits 0 through 9). Binary floating-point numbers are stored using binary 
precision (the digits 0 and 1). Such a storage scheme cannot represent all values using decimal precision exactly. 
Frequently, the error that occurs when converting a value from decimal to binary precision is undone when the 
value is converted back from binary to decimal precision. The literal 0.1 is such an example. 


Oracle Database provides two numeric data types exclusively for floating-point numbers: 
BINARY_FLOAT 


BINARY_FLOAT is a 32-bit, single-precision floating-point number data type. Each BINARY_FLOAT value 
requires 4 bytes. 


BINARY_DOUBLE 


BINARY_DOUBLE is a 64-bit, double-precision floating-point number data type. 
Each BINARY_DOUBLE value requires 8 bytes. 


Ina NUMBER column, floating point numbers have decimal precision. In 
a BINARY_FLOAT or BINARY_DOUBLE column, floating-point numbers have binary precision. The binary 
floating-point numbers support the special values infinity and NaN (not a number). 


Numeric Precedence 


Numeric precedence determines, for operations that support numeric data types, the data type Oracle uses if the 
arguments to the operation have different data types. BINARY_DOUBLE has the highest numeric precedence, 
followed by BINARY_FLOAT, and finally by NUMBER. Therefore, in any operation on multiple numeric values: 


If any of the operands is BINARY_DOUBLE, then Oracle attempts to convert all the operands implicitly 
to BINARY_DOUBLE before performing the operation. 


If none of the operands is BINARY_DOUBLE but any of the operands is BINARY_FLOAT, then Oracle 
attempts to convert all the operands implicitly to BINARY _FLOAT before performing the operation. 


- Otherwise, Oracle attempts to convert all the operands to NUMBER before performing the operation. 
If any implicit conversion is needed and fails, then the operation fails. 


In the context of other data types, numeric data types have lower precedence than the datetime/interval data types 
and higher precedence than character and all other data types. 


LONG Data Type 


Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB, BLOB) instead. LONG columns 
are supported only for backward compatibility. 


LONG columns store variable-length character strings containing up to 2 gigabytes -1, or 2 ° -1 
bytes. LONG columns have many of the characteristics of VARCHAR2 columns. You can use LONG columns to 
store long text strings. The length of LONG values may be limited by the memory available on your computer. 


Oracle also recommends that you convert existing LONG columns to LOB columns. LOB columns are subject to 
far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, 
whereas LONG functionality has been static for several releases. 


You can reference LONG columns in SQL statements in these places: 


SELECT lists 
SET clauses of UPDATE statements 
- VALUES clauses of INSERT statements 


The use of LONG values is subject to these restrictions: 


A table can contain only one LONG column. 
- You cannot create an object type with a LONG attribute. 


LONG columns cannot appear in WHERE clauses or in integrity constraints (except that they can appear 
in NULL and NOT NULL constraints). 


« LONG columns cannot be indexed. 
LONG data cannot be specified in regular expressions. 
A stored function cannot return a LONG value. 


+ You can declare a variable or argument of a PL/SQL program unit using the LONG data type. However, 
you cannot then call the program unit from SQL. 


Within a single SQL statement, all LONG columns, updated tables, and locked tables must be located on 
the same database. 


- LONG and LONG RAW columns cannot be used in distributed SQL statements and cannot be replicated. 


If a table has both LONG and LOB columns, then you cannot bind more than 4000 bytes of data to both 
the LONG and LOB columns in the same SQL statement. However, you can bind more than 4000 bytes of 
data to either the LONG or the LOB column. 


In addition, LONG columns cannot appear in these parts of SQL statements: 


GROUP BY clauses, ORDER BY clauses, or CONNECT BY clauses or with the DISTINCT operator 
in SELECT statements 


The UNIQUE operator of a SELECT statement 
- The column list of a CREATE CLUSTER statement 

The CLUSTER clause of a CREATE MATERIALIZED VIEW statement 
e SQL built-in functions, expressions, or conditions 

SELECT lists of queries containing GROUP BY clauses 

SELECT lists of subqueries or queries combined by the UNION, INTERSECT, or MINUS set operators 
e SELECT lists of CREATE TABLE ... AS SELECT statements 

ALTER TABLE ... MOVE statements 

SELECT lists in subqueries in INSERT statements 


Triggers can use the LONG data type in the following manner: 


A SQL statement within a trigger can insert data into a LONG column. 


If data from a LONG column can be converted to a constrained data type (such 
as CHAR and VARCHAR2), then a LONG column can be referenced in a SQL statement within a trigger. 


Variables in triggers cannot be declared using the LONG data type. 
:NEW and :OLD cannot be used with LONG columns. 


You can use Oracle Call Interface functions to retrieve a portion of a LONG value from the database. 
Datetime and Interval Data Types 


The datetime data types are DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, 

and TIMESTAMP WITH LOCAL TIME ZONE. Values of datetime data types are sometimes called datetimes . 
The interval data types are INTERVAL YEAR TO MONTH and INTERVAL DAY TO SECOND. Values of 
interval data types are sometimes called intervals . 


Both datetimes and intervals are made up of fields. The values of these fields determine the value of the data type. 


To avoid unexpected results in your DML operations on datetime data, you can verify the database and session 
time zones by querying the built-in SQL functions DBTIMEZONE and SESSIONTIMEZONE. If the time zones 
have not been set manually, then Oracle Database uses the operating system time zone by default. If the operating 
system time zone is not a valid Oracle time zone, then Oracle uses UTC as the default value. 


Datetime Fields and Values 


Valid Values for 
Datetime Field Valid Values for Datetime INTERVAL 
YEAR -4712 to 9999 (excluding year 0) Any positive or negative 
integer 
MONTH 01 to 12 Oto 11 
DAY 01 to 31 (limited by the values Any positive or negative 


of MONTH and YEAR, according to the rules of integer 
the current NLS calendar parameter) 


HOUR 00 to 23 0 to 23 


MINUTE 00 to 59 0 to 59 


Valid Values for 


Datetime Field Valid Values for Datetime INTERVAL 

SECOND 00 to 59.9(n), where 9(n) is the precision of time 0 to 59.9(n), where 9(n) is 
fractional seconds. The 9(n) portion is not the precision of interval 
applicable for DATE. fractional seconds 

TIMEZONE_HOUR -12 to 14 (This range accommodates daylight Not applicable 


saving time changes.) Not applicable 
for DATE or TIMESTAMP. 


TIMEZONE_MINUTE 00 to 59. Not applicable Not applicable 
(See note at end of table) for DATE or TIMESTAMP. 


TIMEZONE_REGION Query the TZNAME column of Not applicable 
the VSTIMEZONE_NAMES data dictionary view. 
Not applicable for DATE or TIMESTAMP. 


TIMEZONE_ABBR Query the TZABBREV column of Not applicable 
the VSTIMEZONE_NAMES data dictionary view. 
Not applicable for DATE or TIMESTAMP. 


DATE Data Type 


The DATE data type stores date and time information. Although date and time information can be represented in 
both character and number data types, the DATE data type has special associated properties. For each DATE value, 
Oracle stores the following information: year, month, day, hour, minute, and second. 


You can specify a DATE value as a literal, or you can convert a character or numeric value to a date value with 
the TO_DATE function. 


Using Julian Days 


A Julian day number is the number of days since January 1, 4712 BC. Julian days allow continuous dating from a 
common reference. You can use the date format model "J" with date functions TO_DATE and TO_CHAR to 
convert between Oracle DATE values and their Julian equivalents. 


The default date values are determined as follows: 
The year is the current year, as returned by SYSDATE. 
- The month is the current month, as returned by SYSDATE. 
The day is 01 (the first day of the month). 


The hour, minute, and second are all 0. 


These default values are used in a query that requests date values where the date itself is not specified, as in the 
following example, which is issued in the month of May: 


SELECT TO_DATE(‘2009', 'YYYY') 
FROM DUAL; 


TO_DATE(' 


01-MAY-09 


Example 


This statement returns the Julian equivalent of January 1, 2009: 


SELECT TO_CHAR(TO_DATE(‘01-01-2009', '"MM-DD-YYYY’),'J') 
FROM DUAL; 


TO_CHAR 


2454833 


TIMESTAMP Data Type 


The TIMESTAMP data type is an extension of the DATE data type. It stores the year, month, and day of 

the DATE data type, plus hour, minute, and second values. This data type is useful for storing precise time values 
and for collecting and evaluating date information across geographic regions. Specify the TIMESTAMP data type 
as follows: 


TIMESTAMP [( fractional_seconds_precision )] 


where fractional_seconds_precision optionally specifies the number of digits Oracle stores in the fractional part 
of the SECOND datetime field. When you create a column of this data type, the value can be a number in the 
range 0 to 9. The default is 6. 


TIMESTAMP WITH TIME ZONE Data Type 


TIMESTAMP WITH TIME ZONE is a variant of TIMESTAMP that includes a time zone region name ora 
time zone offset in its value. The time zone offset is the difference (in hours and minutes) between local time and 
UTC (Coordinated Universal Time—formerly Greenwich Mean Time). This data type is useful for preserving 
local time zone information. 


Specify the TIMESTAMP WITH TIME ZONE data type as follows: 


TIMESTAMP [( fractional_seconds_precision )] WITH TIME ZONE 


where fractional_seconds_precision optionally specifies the number of digits Oracle stores in the fractional part 
of the SECOND datetime field. When you create a column of this data type, the value can be a number in the 
range 0 to 9. The default is 6. 


TIMESTAMP WITH LOCAL TIME ZONE Data Type 


TIMESTAMP WITH LOCAL TIME ZONE is another variant of TIMESTAMP that is sensitive to time zone 
information. It differs from TIMESTAMP WITH TIME ZONE in that data stored in the database is normalized to 
the database time zone, and the time zone information is not stored as part of the column data. When a user 
retrieves the data, Oracle returns it in the user's local session time zone. This data type is useful for date 
information that is always to be displayed in the time zone of the client system in a two-tier application. 


Specify the TIMESTAMP WITH LOCAL TIME ZONE data type as follows: 


TIMESTAMP [( fractional_seconds_precision )] WITH LOCAL TIME ZONE 


where fractional_seconds_precision optionally specifies the number of digits Oracle stores in the fractional part 
of the SECOND datetime field. When you create a column of this data type, the value can be a number in the 
range 0 to 9. The default is 6. 


INTERVAL YEAR TO MONTH Data Type 


INTERVAL YEAR TO MONTH stores a period of time using the YEAR and MONTH datetime fields. This data 
type is useful for representing the difference between two datetime values when only the year and month values 
are significant. 


Specify INTERVAL YEAR TO MONTH as follows: 


INTERVAL YEAR [( year_precision )] TO MONTH 


where year_precision is the number of digits in the YEAR datetime field. The default value of year_precision is 
2: 


INTERVAL DAY TO SECOND Data Type 


INTERVAL DAY TO SECOND stores a period of time in terms of days, hours, minutes, and seconds. This data 
type is useful for representing the precise difference between two datetime values. 


Specify this data type as follows: 


INTERVAL DAY [( day_precision )] 
TO SECOND [( fractional_seconds_precision )] 


where 


day_precision is the number of digits in the DAY datetime field. Accepted values are 0 to 9. The default is 
2. 


- fractional_seconds_precision is the number of digits in the fractional part of the SECOND datetime field. 
Accepted values are 0 to 9. The default is 6. 


Datetime/Interval Arithmetic 


You can perform a number of arithmetic operations on date (DATE), timestamp 

(TIMESTAMP, TIMESTAMP WITH TIME ZONE, and TIMESTAMP WITH LOCAL TIME ZONE) and interval 
(INTERVAL DAY TO SECOND and INTERVAL YEAR TO MONTH) data. Oracle calculates the results based on 
the following rules: 


- You can use NUMBER constants in arithmetic operations on date and timestamp values, but not interval 
values. Oracle internally converts timestamp values to date values and interprets NUMBER constants in 
arithmetic datetime and interval expressions as numbers of days. For example, SYSDATE + 1 is 
tomorrow. SYSDATE - 7 is one week ago. SYSDATE + (10/1440) is ten minutes from now. Subtracting 
the hire_date column of the sample table employees from SYSDATE returns the number of days since 
each employee was hired. You cannot multiply or divide date or timestamp values. 


- Oracle implicitly converts BINARY_FLOAT and BINARY_DOUBLE operands to NUMBER. 


Each DATE value contains a time component, and the result of many date operations include a fraction. 
This fraction means a portion of one day. For example, 1.5 days is 36 hours. These fractions are also 
returned by Oracle built-in functions for common operations on DATE data. For example, 

the MONTHS_BETWEEN function returns the number of months between two dates. The fractional 
portion of the result represents that portion of a 31-day month. 


- If one operand is a DATE value or a numeric value, neither of which contains time zone or fractional 
seconds components, then: 
o Oracle implicitly converts the other operand to DATE data. The exception is multiplication of a 
numeric value times an interval, which returns an interval. 


o If the other operand has a time zone value, then Oracle uses the session time zone in the returned 
value. 


o If the other operand has a fractional seconds value, then the fractional seconds value is lost. 


When you pass a timestamp, interval, or numeric value to a built-in function that was designed only for 
the DATE data type, Oracle implicitly converts the non-DATE value to a DATE value. 


When interval calculations return a datetime value, the result must be an actual datetime value or the 
database returns an error. For example, the next two statements return errors: 


SELECT TO_DATE('31-AUG-2004',,DD-MON-YYYY’') + TO_YMINTERVAL('0-1') 
FROM DUAL; 


SELECT TO_DATE(‘29-FEB-2004',,DD-MON-YYYY') + TO_YMINTERVAL(‘1-0') 
FROM DUAL; 


The first fails because adding one month to a 31-day month would result in September 31, which is not a 
valid date. The second fails because adding one year to a date that exists only every four years is not 
valid. However, the next statement succeeds, because adding four years to a February 29 date is valid: 


SELECT TO_DATE(29-FEB-2004', 'DD-MON-YYYY') + TO_YMINTERVAL(‘4-0') 
FROM DUAL; 


TO_DATE(' 


29-FEB-08 


Oracle performs all timestamp arithmetic in UTC time. For TIMESTAMP WITH LOCAL TIME ZONE, 
Oracle converts the datetime value from the database time zone to UTC and converts back to the database 
time zone after performing the arithmetic. For TIMESTAMP WITH TIME ZONE, the datetime value is 
always in UTC, so no conversion is necessary. 


Matrix of Datetime Arithmetic 


Operand & Operator DATE TIMESTAMP INTERVAL Numeric 
DATE 

+ = — DATE DATE 
- NUMBER INTERVAL DATE DATE 
* 5 = = = 

/ = = = = 
TIMESTAMP 

+ — — TIMESTAMP DATE 
- INTERVAL INTERVAL TIMESTAMP DATE 
* — — — — 

/ _ _ = -n 


INTERVAL 


Operand & Operator DATE TIMESTAMP INTERVAL Numeric 


+ DATE TIMESTAMP INTERVAL — 

7 = = INTERVAL — 

* — — — INTERVAL 

/ — — — INTERVAL 

Numeric 

+ DATE DATE — NA 

- — — — NA 

* — — INTERVAL NA 

/ — — — NA 
Examples 


You can add an interval value expression to a start time. Consider the sample table oe.orders with a 
column order_date. The following statement adds 30 days to the value of the order_date column: 


SELECT order_id, order_date + INTERVAL '30' DAY AS "Due Date" 
FROM orders 
ORDER BY order_id, "Due Date"; 


Support for Daylight Saving Times 


Oracle Database automatically determines, for any given time zone region, whether daylight saving is in effect and 
returns local time values accordingly. The datetime value is sufficient for Oracle to determine whether daylight 
saving time is in effect for a given region in all cases except boundary cases . A boundary case occurs during the 
period when daylight saving goes into or comes out of effect. For example, in the US-Pacific region, when 
daylight saving goes into effect, the time changes from 2:00 a.m. to 3:00 a.m. The one hour interval between 2 and 
3 a.m. does not exist. When daylight saving goes out of effect, the time changes from 2:00 a.m. back to 1:00 a.m., 
and the one-hour interval between 1 and 2 a.m. is repeated. 


To resolve these boundary cases, Oracle uses the TZR and TZD format elements. TZR represents the time zone 
region name in datetime input strings. Examples are 'Australia/North', 'UTC', and ‘Singapore’. TZD represents an 
abbreviated form of the time zone region name with daylight saving information. Examples are 'PST" for 
US/Pacific standard time and 'PDT' for US/Pacific daylight time. To see a listing of valid values for 

the TZR and TZD format elements, query the TZNAME and TZABBREV columns of 

the VSTIMEZONE_NAMES dynamic performance view. 


Datetime and Interval Examples 


The following example shows how to specify some datetime and interval data types. 


CREATE TABLE time_table 
(start_time TIMESTAMP, 
duration_1 INTERVAL DAY (6) TO SECOND (5), 
duration_2 INTERVAL YEAR TO MONTH); 


The start_time column is of type TIMESTAMP. The implicit fractional seconds precision of TIMESTAMP is 6. 


The duration_1 column is of type INTERVAL DAY TO SECOND. The maximum number of digits in field DAY is 
6 and the maximum number of digits in the fractional second is 5. The maximum number of digits in all other 
datetime fields is 2. 


The duration_2 column is of type INTERVAL YEAR TO MONTH. The maximum number of digits of the value in 
each field (YEAR and MONTH) is 2. 


Interval data types do not have format models. Therefore, to adjust their presentation, you must combine character 
functions such as EXTRACT and concatenate the components. For example, the following examples query 

the hr.employees and oe.orders tables, respectively, and change interval output from the form " yy - mm" to " yy 
years mm months" and from " dd - hh" to " dddd days hh hours": 


SELECT last_name, EXTRACT(YEAR FROM (SYSDATE - hire_date) YEAR TO MONTH) 
|| "years ' 
| EXTRACT(MONTH FROM (SYSDATE - hire_date) YEAR TO MONTH) 
|| ' months' "Interval" 
FROM employees; 


LAST_NAME Interval 
OConnell 2 years 3 months 
Grant 1 years 9 months 
Whalen 6 years 1 months 
Hartstein 5 years 8 months 
Fay 4 years 2 months 
Mavris 7 years 4 months 
Baer 7 years 4 months 
Higgins 7 years 4 months 
Gietz 7 years 4 months 


SELECT order_id, EXTRACT(DAY FROM (SYSDATE - order_date) DAY TO SECOND) 
|| ' days ' 
| EXTRACT(HOUR FROM (SYSDATE - order_date) DAY TO SECOND) 
||‘ hours' "Interval" 
FROM orders; 


ORDER _ID Interval 
2458 780 days 23 hours 
2397 685 days 22 hours 
2454 733 days 21 hours 
2354 447 days 20 hours 
2358 635 days 20 hours 
2381 508 days 18 hours 
2440 765 days 17 hours 
2357 1365 days 16 hours 
2394 602 days 15 hours 
2435 763 days 15 hours 


RAW and LONG RAW Data Types 


The RAW and LONG RAW data types store data that is not to be explicitly converted by Oracle Database when 
moving data between different systems. These data types are intended for binary data or byte strings. For example, 


you can use LONG RAW to store graphics, sound, documents, or arrays of binary data, for which the interpretation 
is dependent on the use. 


Oracle strongly recommends that you convert LONG RAW columns to binary LOB (BLOB) columns. LOB 
columns are subject to far fewer restrictions than LONG columns. 


RAW is a variable-length data type like VARCHAR2, except that Oracle Net (which connects client software to a 
database or one database to another) and the Oracle import and export utilities do not perform character conversion 
when transmitting RAW or LONG RAW data. In contrast, Oracle Net and the Oracle import and export utilities 
automatically convert CHAR, VARCHAR2, and LONG data between different database character sets, if data is 
transported between databases, or between the database character set and the client character set, if data is 
transported between a database and a client. The client character set is determined by the type of the client 
interface, such as OCI or JDBC, and the client configuration (for example, the NLS_LANG environment variable). 


When Oracle implicitly converts RAW or LONG RAW data to character data, the resulting character value 
contains a hexadecimal representation of the binary input, where each character is a hexadecimal digit (0-9, A-F) 
representing four consecutive bits of RAW data. For example, one byte of RAW data with bits 11001011 becomes 
the value CB. 


When Oracle implicitly converts character data to RAW or LONG RAW, it interprets each consecutive input 
character as a hexadecimal representation of four consecutive bits of binary data and builds the 

resulting RAW or LONG RAW value by concatenating those bits. If any of the input characters is not a 
hexadecimal digit (0-9, A-F, a-f), then an error is reported. If the number of characters is odd, then the result is 
undefined. 


The SQL functions RAWTOHEX and HEXTORAW perform explicit conversions that are equivalent to the above 
implicit conversions. Other types of conversions between RAW and character data are possible with functions in 
the Oracle-supplied PL/SQL packages UTL_RAW and UTL_I18N. 


Large Object (LOB) Data Types 


The built-in LOB data types BLOB, CLOB, and NCLOB (stored internally) and BFILE (stored externally) can 
store large and unstructured data such as text, image, video, and spatial data. The size of BLOB, CLOB, 

and NCLOB data can be up to (2 * -1 bytes) * (the value of the CHUNK parameter of LOB storage). If the 
tablespaces in your database are of standard block size, and if you have used the default value of 

the CHUNK parameter of LOB storage when creating a LOB column, then this is equivalent to (2 ** -1 bytes) * 
(database block size). BFILE data can be up to 2 “ -1 bytes, although your operating system may impose 
restrictions on this maximum. 


When creating a table, you can optionally specify different tablespace and storage characteristics for LOB columns 
or LOB object attributes from those specified for the table. 


CLOB, NCLOB, and BLOB values up to approximately 4000 bytes are stored inline if you enable storage in row 
at the time the LOB column is created. LOBs greater than 4000 bytes are always stored externally. 


LOB columns contain LOB locators that can refer to internal (in the database) or external (outside the database) 
LOB values. Selecting a LOB from a table actually returns the LOB locator and not the entire LOB value. 

The DBMS_LOB package and Oracle Call Interface (OCI) operations on LOBs are performed through these 
locators. 


LOBs are similar to LONG and LONG RAW types, but differ in the following ways: 


LOBs can be attributes of an object type (user-defined data type). 


- The LOB locator is stored in the table column, either with or without the actual LOB 
value. BLOB, NCLOB, and CLOB values can be stored in separate tablespaces. BFILE data is stored in an 
external file on the server. 


When you access a LOB column, the locator is returned. 


- A LOB can be up to (2 ? -1 bytes)*(database block size) in size. BFILE data can be up to 2 “ -1 bytes, 
although your operating system may impose restrictions on this maximum. 


LOBs permit efficient, random, piece-wise access to and manipulation of data. 
You can define more than one LOB column in a table. 

- With the exception of NCLOB, you can define one or more LOB attributes in an object. 
You can declare LOB bind variables. 

- You can select LOB columns and LOB attributes. 


You can insert a new row or update an existing row that contains one or more LOB columns or an object 
with one or more LOB attributes. In update operations, you can set the internal LOB value to NULL, 
empty, or replace the entire LOB with data. You can set the BFILE to NULL or make it point to a different 
file. 


- You can update a LOB row-column intersection or a LOB attribute with another LOB row-column 
intersection or LOB attribute. 


You can delete a row containing a LOB column or LOB attribute and thereby also delete the LOB value. 
For BFILEs, the actual operating system file is not deleted. 


You can access and populate rows of an inline LOB column (a LOB column stored in the database) or a LOB 
attribute (an attribute of an object type column stored in the database) simply by issuing 
an INSERT or UPDATE statement. 


BFILE Data Type 


The BFILE data type enables access to binary file LOBs that are stored in file systems outside Oracle Database. 
A BFILE column or attribute stores a BFILE locator, which serves as a pointer to a binary file on the server file 
system. The locator maintains the directory name and the filename. 


You can change the filename and path of a BFILE without affecting the base table by using 
the BFILENAME function. 


Binary file LOBs do not participate in transactions and are not recoverable. Rather, the underlying operating 
system provides file integrity and durability. BFILE data can be up to 2 “ -1 bytes, although your operating system 
may impose restrictions on this maximum. 


The database administrator must ensure that the external file exists and that Oracle processes have operating 
system read permissions on the file. 


The BFILE data type enables read-only support of large binary files. You cannot modify or replicate such a file. 
Oracle provides APIs to access file data. The primary interfaces that you use to access file data are 
the DBMS_LOB package and Oracle Call Interface (OCI). 


BLOB Data Type 


The BLOB data type stores unstructured binary large objects. BLOB objects can be thought of as bitstreams with 
no character set semantics. BLOB objects can store binary data up to (4 gigabytes -1) * (the value of 

the CHUNK parameter of LOB storage). If the tablespaces in your database are of standard block size, and if you 
have used the default value of the CHUNK parameter of LOB storage when creating a LOB column, then this is 
equivalent to (4 gigabytes - 1) * (database block size). 


BLOB objects have full transactional support. Changes made through SQL, the DBMS_LOB package, or Oracle 
Call Interface (OCI) participate fully in the transaction. BLOB value manipulations can be committed and rolled 
back. However, you cannot save a BLOB locator in a PL/SQL or OCI variable in one transaction and then use it in 
another transaction or session. 


CLOB Data Type 


The CLOB data type stores single-byte and multibyte character data. Both fixed-width and variable-width 
character sets are supported, and both use the database character set. CLOB objects can store up to (4 gigabytes -1) 
* (the value of the CHUNK parameter of LOB storage) of character data. If the tablespaces in your database are of 


standard block size, and if you have used the default value of the CHUNK parameter of LOB storage when 
creating a LOB column, then this is equivalent to (4 gigabytes - 1) * (database block size). 


CLOB objects have full transactional support. Changes made through SQL, the DBMS_LOB package, or Oracle 
Call Interface (OCI) participate fully in the transaction. CLOB value manipulations can be committed and rolled 
back. However, you cannot save a CLOB locator in a PL/SQL or OCI variable in one transaction and then use it in 
another transaction or session. 


NCLOB Data Type 


The NCLOB data type stores Unicode data. Both fixed-width and variable-width character sets are supported, and 
both use the national character set. NCLOB objects can store up to (4 gigabytes -1) * (the value of 

the CHUNK parameter of LOB storage) of character text data. If the tablespaces in your database are of standard 
block size, and if you have used the default value of the CHUNK parameter of LOB storage when creating a LOB 
column, then this is equivalent to (4 gigabytes - 1) * (database block size). 


NCLOB objects have full transactional support. Changes made through SQL, the DBMS_LOB package, or OCI 
participate fully in the transaction. NCLOB value manipulations can be committed and rolled back. However, you 
cannot save an NCLOB locator in a PL/SQL or OCI variable in one transaction and then use it in another 
transaction or session. 


Extended Data Types 


Beginning with Oracle Database 12 c , you can specify a maximum size of 32767 bytes for 
the VARCHAR2, NVARCHAR2, and RAW data types. You can control whether your database supports this new 
maximum size by setting the initialization parameter MAX_STRING_SIZE as follows: 


If MAX_STRING_SIZE = STANDARD, then the size limits for releases prior to Oracle Database 12 c 
apply: 4000 bytes for the VARCHAR2 and NVARCHAR2 data types, and 2000 bytes for the RAW data 
type. This is the default. 


If MAX_STRING_SIZE = EXTENDED, then the size limit is 32767 bytes for 
the VARCHAR2, NVARCHAR2, and RAW data types. 


Rowid Data Types 


Each row in the database has an address. The sections that follow describe the two forms of row address in an 
Oracle Database. 


ROWID Data Type 


The rows in heap-organized tables that are native to Oracle Database have row addresses called rowids . You can 
examine a rowid row address by querying the pseudocolumn ROWID. Values of this pseudocolumn are strings 
representing the address of each row. These strings have the data type ROWID. You can also create tables and 
clusters that contain actual columns having the ROWID data type. Oracle Database does not guarantee that the 
values of such columns are valid rowids. 


Rowids contain the following information: 
The data block of the data file containing the row. The length of this string depends on your operating 
system. 
- The row in the data block. 


The database file containing the row. The first data file has the number 1. The length of this string 
depends on your operating system. 


- The data object number , which is an identification number assigned to every database segment. You can 
retrieve the data object number from the data dictionary views USER_OBJECTS, DBA_OBJECTS, 
and ALL_OBJECTS. Objects that share the same segment (clustered tables in the same cluster, for 
example) have the same object number. 


Rowids are stored as base 64 values that can contain the characters A-Z, a-z, 0-9, and the plus sign (+) and forward 
slash (/). Rowids are not available directly. You can use the supplied package DBMS_ROWID to interpret rowid 
contents. The package functions extract and provide information on the four rowid elements listed above. 


UROWID Data Type 


The rows of some tables have addresses that are not physical or permanent or were not generated by Oracle 
Database. For example, the row addresses of index-organized tables are stored in index leaves, which can move. 
Rowids of foreign tables (such as DB2 tables accessed through a gateway) are not standard Oracle rowids. 


Oracle uses universal rowids ( urowids ) to store the addresses of index-organized and foreign tables. Index- 
organized tables have logical urowids and foreign tables have foreign urowids. Both types of urowid are stored in 
the ROWID pseudocolumn (as are the physical rowids of heap-organized tables). 


Oracle creates logical rowids based on the primary key of the table. The logical rowids do not change as long as 
the primary key does not change. The ROWID pseudocolumn of an index-organized table has a data type 

of UROWID. You can access this pseudocolumn as you would the ROWID pseudocolumn of a heap-organized 
table (using a SELECT ... ROWID statement). If you want to store the rowids of an index-organized table, then 
you can define a column of type UROWID for the table and retrieve the value of the ROWID pseudocolumn into 
that column. 


User-Defined Types 


User-defined data types use Oracle built-in data types and other user-defined data types as the building blocks of 
object types that model the structure and behavior of data in applications. The sections that follow describe the 
various categories of user-defined types. 


Object Types 


Object types are abstractions of the real-world entities, such as purchase orders, that application programs deal 
with. An object type is a schema object with three kinds of components: 


A name, which identifies the object type uniquely within that schema. 


Attributes , which are built-in types or other user-defined types. Attributes model the structure of the real- 
world entity. 


Methods , which are functions or procedures written in PL/SQL and stored in the database, or written in a 
language like C or Java and stored externally. Methods implement operations the application can perform 
on the real-world entity. 


REF Data Types 


An object identifier (represented by the keyword OID) uniquely identifies an object and enables you to reference 
the object from other objects or from relational tables. A data type category called REF represents such references. 
A REF data type is a container for an object identifier. REF values are pointers to objects. 


When a REF value points to a nonexistent object, the REF is said to be "dangling". A dangling REF is different 
from a null REF. To determine whether a REF is dangling or not, use the condition IS [NOT] DANGLING. For 
example, given object view oc_orders in the sample schema oe, the column customer_ref is of type REF to 
type customer_typ, which has an attribute cust_email: 


SELECT o.customer_ref.cust_email 
FROM oc_orders o 
WHERE o.customer_ref IS NOT DANGLING; 


Varrays 


An array is an ordered set of data elements. All elements of a given array are of the same data type. Each element 
has an index , which is a number corresponding to the position of the element in the array. 


The number of elements in an array is the size of the array. Oracle arrays are of variable size, which is why they 
are called varrays . You must specify a maximum size when you declare the varray. 


When you declare a varray, it does not allocate space. It defines a type, which you can use as: 


- The data type of a column of a relational table 
An object type attribute 


A PL/SQL variable, parameter, or function return type 


Oracle normally stores an array object either in line (as part of the row data) or out of line (in a LOB), depending 
on its size. However, if you specify separate storage characteristics for a varray, then Oracle stores it out of line, 
regardless of its size. 


Nested Tables 


A nested table type models an unordered set of elements. The elements may be built-in types or user-defined types. 
You can view a nested table as a single-column table or, if the nested table is an object type, as a multicolumn 
table, with a column for each attribute of the object type. 


A nested table definition does not allocate space. It defines a type, which you can use to declare: 
The data type of a column of a relational table 


An object type attribute 


e A PL/SQL variable, parameter, or function return type 


When a nested table appears as the type of a column in a relational table or as an attribute of the underlying object 
type of an object table, Oracle stores all of the nested table data in a single table, which it associates with the 
enclosing relational or object table. 


Oracle-Supplied Types 


Oracle provides SQL-based interfaces for defining new types when the built-in or ANSI-supported types are not 
sufficient. The behavior for these types can be implemented in C/C++, Java, or PL/ SQL. Oracle Database 
automatically provides the low-level infrastructure services needed for input-output, heterogeneous client-side 
access for new data types, and optimizations for data transfers between the application and the database. 


These interfaces can be used to build user-defined (or object) types and are also used by Oracle to create some 
commonly useful data types. Several such data types are supplied with the server, and they serve both broad 
horizontal application areas (for example, the Any types) and specific vertical ones (for example, the spatial types). 


The Oracle-supplied types, along with cross-references to the documentation of their implementation and use, are 
described in the following sections: 


- Any Types 
XML Types 
e Spatial Types 


Any Types 


The Any types provide highly flexible modeling of procedure parameters and table columns where the actual type 
is not known. These data types let you dynamically encapsulate and access type descriptions, data instances, and 
sets of data instances of any other SQL type. These types have OCI and PL/SQL interfaces for construction and 
access. 


ANYTYPE 
This type can contain a type description of any named SQL type or unnamed transient type. 


ANYDATA 


This type contains an instance of a given type, with data, plus a description of the type. ANYDATA can be used as 
a table column data type and lets you store heterogeneous values in a single column. The values can be of SQL 
built-in types as well as user-defined types. 


ANYDATASET 


This type contains a description of a given type plus a set of data instances of that type. ANYDATASET can be 
used as a procedure parameter data type where such flexibility is needed. The values of the data instances can be of 
SQL built-in types as well as user-defined types. 


XML Types 


Extensible Markup Language (XML) is a standard format developed by the World Wide Web Consortium (W3C) 
for representing structured and unstructured data on the World Wide Web. Universal resource identifiers (URIs) 
identify resources such as Web pages anywhere on the Web. Oracle provides types to handle XML and URI data, 
as well as a class of URIs called DBURIRef types to access data stored within the database itself. It also provides a 
set of types to store and access both external and internal URIs from within the database. 


XMLType 


This Oracle-supplied type can be used to store and query XML data in the database. XMLType has member 
functions you can use to access, extract, and query the XML data using XPath expressions. XPath is another 
standard developed by the W3C committee to traverse XML documents. Oracle XMLType functions support many 
W3C XPath expressions. Oracle also provides a set of SQL functions and PL/SQL packages to 

create XMLType values from existing relational or object-relational data. 


XMLType is a system-defined type, so you can use it as an argument of a function or as the data type of a table or 
view column. You can also create tables and views of XMLType. When you create an XMLType column in a table, 
you can choose to store the XML data in a CLOB column, as binary XML (stored internally as a CLOB), or object 
relationally. 


You can also register the schema (using the DBMS_XMLSCHEMA package) and create a table or column 
conforming to the registered schema. In this case Oracle stores the XML data in underlying object-relational 
columns by default, but you can specify storage in a CLOB or binary XML column even for schema-based data. 


Queries and DML on XMLType columns operate the same regardless of the storage mechanism. 
URI Data Types 


Oracle supplies a family of URI types—URIType, DBURIType, XDBURIType, and HTTPURIType—which are 
related by an inheritance hierarchy. URIType is an object type and the others are subtypes of URIType. 

Since URIType is the supertype, you can create columns of this type and store DBURIType or HTTPURIType type 
instances in this column. 


HTTPURIType 


You can use HTTPURIType to store URLs to external Web pages or to files. Oracle accesses these files using 
HTTP (Hypertext Transfer Protocol). 


XDBURIType 


You can use XDBURIType to expose documents in the XML database hierarchy as URIs that can be embedded in 
any URIType column in a table. The XDBURIType consists of a URL, which comprises the hierarchical name of 
the XML document to which it refers and an optional fragment representing the XPath syntax. The fragment is 
separated from the URL part by a pound sign (#). The following lines are examples of XDBURIType: 


/home/oe/doc1.xml 


/home/oe/doc1.xml#/orders/order_item 


DBURIType 


DBURIType can be used to store DBURIRef values, which reference data inside the database. 
Storing DBURIRef values lets you reference data stored inside or outside the database and access the data 
consistently. 


DBURIRef values use an XPath-like representation to reference data inside the database. If you imagine the 
database as an XML tree, then you would see the tables, rows, and columns as elements in the XML document. 
For example, the sample human resources user hr would see the following XML tree: 


<HR> 
<EMPLOYEES> 
<ROW> 
<EMPLOYEE_ID>205</EMPLOYEE_ID> 
<LAST_NAME>Higgins</LAST_NAME> 
<SALARY>12008</SALARY> 
.. <!-- other columns --> 
</ROW> 
... <!-- other rows --> 
</EMPLOYEES> 
<!-- other tables..--> 
</HR> 
<!-- other user schemas on which you have some privilege on..--> 


The DBURIRef is an XPath expression over this virtual XML document. So to reference the SALARY value in 
the EMPLOYEES table for the employee with employee number 205, you can write a DBURIRef as, 


/HR/EMPLOYEES/ROW[EMPLOYEE_ID=205]/SALARY 


Using this model, you can reference data stored in CLOB columns or other columns and expose them as URLs to 
the external world. 


URIFactory Package 


Oracle also provides the URIFactory package, which can create and return instances of the various subtypes of 
the URITypes. The package analyzes the URL string, identifies the type of URL (HTTP, DBURI, and so on), and 
creates an instance of the subtype. To create a DBURI instance, the URL must begin with the prefix /oradb. For 
example, URIFactory.getURI(‘/oradb/HR/EMPLOYEES') would create a DBURIType instance 

and URIFactory.getUri('/sys/schema') would create an XDBURIType instance. 


Spatial Types 


Oracle Spatial and Graph is designed to make spatial data management easier and more natural to users of 
location-enabled applications, geographic information system (GIS) applications, and geoimaging applications. 
After the spatial data is stored in an Oracle Database, you can easily manipulate, retrieve, and relate it to all the 
other data stored in the database. The following data types are available only if you have installed Oracle Spatial 
and Graph. 


SDO_GEOMETRY 


The geometric description of a spatial object is stored in a single row, in a single column of object 

type SDO_GEOMETRY in a user-defined table. Any table that has a column of type SDO_GEOMETRY must 
have another column, or set of columns, that defines a unique primary key for that table. Tables of this sort are 
sometimes called geometry tables. 


The SDO_GEOMETRY object type has the following definition: 


CREATE TYPE SDO_GEOMETRY AS OBJECT 
(sgo_gtype NUMBER, 
sdo_srid NUMBER, 
sdo_point SDO_POINT_TYPE, 
sdo_elem_info SDO_ ELEM _INFO_ARRAY, 
sdo_ordinates SDO_ORDINATE_ARRAY); 


SDO_TOPO_GEOMETRY 


This type describes a topology geometry, which is stored in a single row, in a single column of object 
type SDO_TOPO_GEOMETRY in a user-defined table. 


The SDO_TOPO_GEOMETRY object type has the following definition: 


CREATE TYPE SDO_TOPO_GEOMETRY AS OBJECT 
(tg_type NUMBER, 
tg_id NUMBER, 
tg_layer_id NUMBER, 
topology_id NUMBER); 
/ 


SDO_GEORASTER 


In the GeoRaster object-relational model, a raster grid or image object is stored in a single row, in a single column 
of object type SDO_GEORASTER in a user-defined table. Tables of this sort are called GeoRaster tables. 


The SDO_GEORASTER object type has the following definition: 
CREATE TYPE SDO_GEORASTER AS OBJECT 
(rasterType NUMBER, 
spatialExtent  SDO_GEOMETRY, 
rasterDataTable VARCHAR2(32), 


rasterID NUMBER, 
metadata XMLType); 


Data Type Comparison Rules 
This section describes how Oracle Database compares values of each data type. 
Numeric Values 


A larger value is considered greater than a smaller one. All negative numbers are less than zero and all positive 
numbers. Thus, -1 is less than 100; -100 is less than -1. 


The floating-point value NaN (not a number) is greater than any other numeric value and is equal to itself. 
Datetime Values 

A later date or timestamp is considered greater than an earlier one. For example, the date equivalent of '29-MAR- 
2005' is less than that of '05-JAN-2006' and the timestamp equivalent of '05-JAN-2006 1:35pm' is greater than that 
of '05-JAN-2005 10:09am’. 


When two timestamps with time zone are compared, they are first normalized to UTC, that is, to the timezone 
offset '+00:00'. For example, the timestamp with time zone equivalent of '16-OCT-2016 05:59am Europe/Warsaw' 


is equal to that of '15-OCT-2016 08:59pm US/Pacific'. Both represent the same absolute point in time, which 
represented in UTC is October 16th, 2016, 03:59am. 


Binary Values 


A binary value of the data type RAW or BLOB is a sequence of bytes. When two binary values are compared, the 
corresponding, consecutive bytes of the two byte sequences are compared in turn. If the first bytes of both 
compared values are different, the binary value that contains the byte with the lower numeric value is considered 
smaller. If the first bytes are equal, second bytes are compared analogously, and so on, until either the compared 
bytes differ or the comparison process reaches the end of one of the values. In the latter case, the value that is 
shorter is considered smaller. 


Binary values of the data type BLOB cannot be compared directly in comparison conditions. However, they can be 
compared with the PL/SQL function DBMS_LOB.COMPARE. 


Character Values 
Character values are compared on the basis of two measures: 


Binary or linguistic collation 


- Blank-padded or nonpadded comparison semantics 
The following subsections describe the two measures. 
Binary and Linguistic Collation 


In binary collation, which is the default, Oracle compares character values like binary values. Two sequences of 
bytes that form the encodings of two character values in their storage character set are treated as binary values and 
compared. The result of this comparison is returned as the result of the binary comparison of the source character 
values. 


For many languages, the binary collation can yield a linguistically incorrect ordering of character values. For 
example, in most common character sets, all the uppercase Latin letters have character codes with lower values 
than all the lowercase Latin letters. Hence, the binary collation yields the following order: 


MacDonald 
MacIntosh 
Macdonald 
Macintosh 


However, most users expect these four values to be presented in the order: 


MacDonald 
Macdonald 
MacIntosh 
Macintosh 


This shows that binary collation may not be suitable even for English character values. 


Oracle Database supports linguistic collations that order strings according to rules of various spoken languages. It 
also supports collation variants that match character values case- and accent-insensitively. Linguistic collations are 
more expensive but they provide superior user experience. 


Restrictions for Linguistic Collations 


Comparison conditions, ORDER BY, GROUP BY and MATCH_RECOGNIZE query 
clauses, COUNT(DISTINCT) and statistical aggregate functions, LIKE conditions, 


and ORDER BY and PARTITION BY analytic clauses generate collation keys when using linguistic collations. 
The collation keys are the same values that are returned by the function NLSSORT. 


Blank-Padded and Nonpadded Comparison Semantics 


With blank-padded semantics, if the two values have different lengths, then Oracle first adds blanks to the end of 
the shorter one so their lengths are equal. Oracle then compares the values character by character up to the first 
character that differs. The value with the greater character in the first differing position is considered greater. If two 
values have no differing characters, then they are considered equal. This rule means that two values are equal if 
they differ only in the number of trailing blanks. Oracle uses blank-padded comparison semantics only when both 
values in the comparison are either expressions of data type CHAR, NCHAR, text literals, or values returned by 
the USER function. 


With nonpadded semantics, Oracle compares two values character by character up to the first character that differs. 
The value with the greater character in that position is considered greater. If two values of different length are 
identical up to the end of the shorter one, then the longer value is considered greater. If two values of equal length 
have no differing characters, then the values are considered equal. Oracle uses nonpadded comparison semantics 
whenever one or both values in the comparison have the data type VARCHAR2 or NVARCHAR2. 


The results of comparing two character values using different comparison semantics may vary. The table that 
follows shows the results of comparing five pairs of character values using each comparison semantic. Usually, the 
results of blank-padded and nonpadded comparisons are the same. The last comparison in the table illustrates the 
differences between the blank-padded and nonpadded comparison semantics. 


Blank-Padded Nonpadded 
‘ac’ > ‘ab' ‘ac’ > 'ab' 
‘ab' > tat 'ab' > tat 
'ab' > tar ‘ab' > ‘q' 

‘ab' = ‘ab’ ‘ab’ = ‘ab’ 
‘a'='a' 'a'>'a' 


Data-Bound Collation 


Starting with Oracle Database 12 c Release 2 (12.2), the collation to use when comparing or matching a given 
character value is associated with the value itself. It is called the data-bound collation . The data-bound collation 
can be viewed as an attribute of the data type of the value. 


In previous Oracle Database releases, the session parameters NLS_COMP and NLS_SORT coarsely determined 
the collation for all collation-sensitive SQL operations in a database session. The data-bound collation architecture 
enables applications to consistently apply language-specific comparison rules to exactly the data that needs these 
rules. 


Oracle Database 12 c Release 2 (12.2) allows you to declare a collation for a table column. When a column is 
passed as an argument to a collation-sensitive SQL operation, the SQL operation uses the column's declared 
collation to process the column's values. If the SQL operation has multiple character arguments that are compared 
to each other, the collation determination rules determine the collation to use. 


There are two types of data-bound collations: 


Named Collation: This collation is a particular set of collating rules specified by a collation name. Named 
collations are the same collations that are specified as values for the NLS_SORT parameter. A named 
collation can be either a binary collation or a linguistic collation. 


Pseudo-collation: This collation does not directly specify the collating rules for a SQL operation. Instead, 
it instructs the operation to check the values of the session parameters NLS_SORT and NLS_COMP for 


the actual named collation to use. Pseudo-collations are the bridge between the new declarative method of 
specifying collations and the old method that uses session parameters. In particular, the pseudo- 

collation USING_NLS_COMP directs a SQL operation to behave exactly as it used to behave before 
Oracle Database 12 c Release 2. 


When you declare a named collation for a column, you statically determine how the column values are compared. 
When you declare a pseudo-collation, you can dynamically control comparison behavior with the session 
parameter NLS_COMP and NLS_SORT. However, static objects, such as indexes and constraints, defined on a 
column declared with a pseudo-collation, fall back to using a binary collation. Dynamically settable collating rules 
cannot be used to compare values for a static object. 


The collation for a character literal or bind variable that is used in an expression is derived from the default 
collation of the database object containing the expression, such as a view or materialized view query, a PL/SQL 
stored unit code, a user-defined type method code, or a standalone DML or query statement. In Oracle Database 12 
c Release 2, the default collation of PL/SQL stored units, user-defined type methods, and standalone SQL 
statements is always the pseudo-collation USING_NLS_COMP. The default collation of views and materialized 
views can be specified in the DEFAULT COLLATION clause of 

the CREATE VIEW and CREATE MATERIALIZED VIEW statements. 


If a SQL operation returns character values, the collation derivation rules determine the derived collation for 
the result, so that its collation is known, when the result is passed as an argument to another collation-sensitive 
SQL operation in the expression tree or to a top-level consumer, such as an SQL statement clause in 

a SELECT statement. If a SQL operation operates on character argument values, then the derived collation of its 
character result is based on the collations of the arguments. Otherwise, the derivation rules are the same as for a 
character literal. 


You can override the derived collation of an expression node, such as a simple expression or an operator result, by 
using the COLLATE operator. 


Oracle Database allows you to declare a case-insensitive collation for a column, table or schema, so that the 
column or all character columns in a table or a schema can be always compared in a case-insensitive way. 


Object Values 


Object values are compared using one of two comparison functions: MAP and ORDER. Both functions compare 
object type instances, but they are quite different from one another. These functions must be specified as part of 
any object type that will be compared with other object types. 


Data Type Precedence 


Oracle uses data type precedence to determine implicit data type conversion, which is discussed in the section that 
follows. Oracle data types take the following precedence: 


Datetime and interval data types 
BINARY_DOUBLE 
BINARY_FLOAT 
NUMBER 

- Character data types 
All other built-in data types 


Data Conversion 


Generally an expression cannot contain values of different data types. For example, an expression cannot multiply 
5 by 10 and then add 'JAMES'. However, Oracle supports both implicit and explicit conversion of values from one 
data type to another. 


Implicit and Explicit Data Conversion 


Oracle recommends that you specify explicit conversions, rather than rely on implicit or automatic conversions, for 
these reasons: 


Implicit 


SQL statements are easier to understand when you use explicit data type conversion functions. 


Implicit data type conversion can have a negative impact on performance, especially if the data type of a 
column value is converted to that of a constant rather than the other way around. 


Implicit conversion depends on the context in which it occurs and may not work the same way in every 
case. For example, implicit conversion from a datetime value to a VARCHAR2 value may return an 
unexpected year depending on the value of the NLS_DATE_FORMAT parameter. 


Algorithms for implicit conversion are subject to change across software releases and among Oracle 
products. Behavior of explicit conversions is more predictable. 


If implicit data type conversion occurs in an index expression, then Oracle Database might not use the 
index because it is defined for the pre-conversion data type. This can have a negative impact on 
performance. 


Data Conversion 


Oracle Database automatically converts a value from one data type to another when such a conversion makes 


sense. 


The tabl 


e shows all possible conversions, without regard to the direction of the conversion or the context in which 


it is made. The rules governing these details follow the table. 


Implicit 


Type Conversion Matrix 


DataType CHAR VARCHAR2 NCHAR NVARCHAR2 DATE DATETIME/INTERVA 
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DATETIME/ 


X 
X 
NVARCHAR2 X 
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NUMBER 
BINARY_FLOAT 


BINARY_DOUBLE 
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You cannot convert LONG to INTERVAL directly, but you can convert LONG to VARCHAR2 using TO_CHAR( 
interval ), and then convert the resulting VARCHAR2 value to INTERVAL. 


The following rules govern implicit data type conversions: 


- During INSERT and UPDATE operations, Oracle converts the value to the data type of the affected 
column. 


During SELECT FROM operations, Oracle converts the data from the column to the type of the target 
variable. 


- When manipulating numeric values, Oracle usually adjusts precision and scale to allow for maximum 
capacity. In such cases, the numeric data type resulting from such operations can differ from the numeric 
data type found in the underlying tables. 


When comparing a character value with a numeric value, Oracle converts the character data to a numeric 
value. 


- Conversions between character values or NUMBER values and floating-point number values can be 
inexact, because the character types and NUMBER use decimal precision to represent the numeric value, 
and the floating-point numbers use binary precision. 


When converting a CLOB value into a character data type such as VARCHAR2, or 
converting BLOB to RAW data, if the data to be converted is larger than the target data type, then the 
database returns an error. 


- During conversion from a timestamp value to a DATE value, the fractional seconds portion of the 
timestamp value is truncated. This behavior differs from earlier releases of Oracle Database, when the 
fractional seconds portion of the timestamp value was rounded. 


Conversions from BINARY FLOAT to BINARY DOUBLE are exact. 

- Conversions from BINARY DOUBLE to BINARY FLOAT are inexact if the BINARY DOUBLE value 
uses more bits of precision that supported by the BINARY_FLOAT. 
When comparing a character value with a DATE value, Oracle converts the character data to DATE. 
When you use a SQL function or operator with an argument of a data type other than the one it accepts, 
Oracle converts the argument to the accepted data type. 
When making assignments, Oracle converts the value on the right side of the equal sign (=) to the data 
type of the target of the assignment on the left side. 
During concatenation operations, Oracle converts from noncharacter data types to CHAR or NCHAR. 


- During arithmetic operations on and comparisons between character and noncharacter data types, Oracle 
converts from any character data type to a numeric, date, or rowid, as appropriate. In arithmetic operations 
between CHAR/VARCHAR2 and NCHAR/NVARCHAR2, Oracle converts to a NUMBER. 


Most SQL character functions are enabled to accept CLOBs as parameters, and Oracle performs implicit 
conversions between CLOB and character types. Therefore, functions that are not yet enabled for CLOBs 
can accept CLOBs through implicit conversion. In such cases, Oracle converts the CLOBs 

to CHAR or VARCHAR2 before the function is invoked. If the CLOB is larger than 4000 bytes, then 
Oracle converts only the first 4000 bytes to CHAR. 


When converting RAW or LONG RAW data to or from character data, the binary data is represented in 
hexadecimal form, with one hexadecimal character representing every four bits of RAW data. 


Comparisons between CHAR and VARCHAR2 and between NCHAR and NVARCHAR2 types may entail 
different character sets. The default direction of conversion in such cases is from the database character set 
to the national character set. 


Conversion Direction of Different Character Types 


SourceData Type to CHAR to VARCHAR2 to NCHAR to NVARCHAR2 


SourceData Type to CHAR to VARCHAR2 to NCHAR to NVARCHAR2 


from CHAR -- VARCHAR2 NCHAR NVARCHAR2 
from VARCHAR2 VARCHAR2 -- NVARCHAR2 NVARCHAR2 
from NCHAR NCHAR NCHAR -- NVARCHAR2 
from NVARCHAR2 NVARCHAR2 NVARCHAR2 -- 
NVARCHAR2 


User-defined types such as collections cannot be implicitly converted, but must be explicitly converted 
using CAST ... MULTISET. 


Implicit Data Conversion Examples 
Text Literal Example 


The text literal '10' has data type CHAR. Oracle implicitly converts it to the NUMBER data type if it appears in a 
numeric expression as in the following statement: 


SELECT salary + '10' 
FROM employees; 


Character and Number Values Example 


When a condition compares a character value and a NUMBER value, Oracle implicitly converts the character 
value to a NUMBER value, rather than converting the NUMBER value to a character value. In the following 
statement, Oracle implicitly converts '200' to 200: 


SELECT last_name 
FROM employees 
WHERE employee_id = '200'; 


Date Example 
In the following statement, Oracle implicitly converts '24-JUN-06' to a DATE value using the default date format 
'DD-MON-YY': 


SELECT last_name 
FROM employees 
WHERE hire_date = '24-JUN-06'; 
Explicit Data Conversion 


You can explicitly specify data type conversions using SQL conversion functions. 


You cannot specify LONG and LONG RAW values in cases in which Oracle can perform implicit data type 
conversion. For example, LONG and LONG RAW values cannot appear in expressions with functions or 
operators. 


Explicit Type Conversions 


SourceData Type 
from CHAR, 
VARCHAR2, 


NCHAR, 
NVARCHAR2 


from NUMBER 


from Datetime/ 
Interval 


from RAW 


from ROWID 


from LONG / 
LONG RAW 


from CLOB, 
NCLOB, BLOB 


from CLOB, 
NCLOB, BLOB 


from 
BINARY_FLOAT 


from 


to 


CHAR,VARCHAR2,NCHAR,NVARCHAR2 


TO_CHAR (char.) 
TO_NCHAR (char.) 


TO_CHAR (number) 
TO_NCHAR (number) 


TO_CHAR (date) 


TO_NCHAR (datetime) 


RAWTOHEX 
RAWTONHEX 


ROWIDTOCHAR 


TO_CHAR 
TO_NCHAR 


TO_CHAR 
TO_NCHAR 


TO_CHAR (char.) 
TO_NCHAR (char.) 


TO_CHAR (char.) 


BINARY_DOUBLE TO_NCHAR (char.) 


Security Considerations for Data Conversion 


to NUMBER 


TO_NUMBER 


TO_NUMBER 


TO_NUMBER 


to Datetime/Interval 


TO_DATE 
TO_TIMESTAMP 
TO_TIMESTAMP_TZ 
TO_YMINTERVAL 
TO_DSINTERVAL 


TO_DATE 
NUMTOYM- 
INTERVAL 
NUMTODS- 
INTERVAL 


When a datetime value is converted to text, either by implicit conversion or by explicit conversion that does not 
specify a format model, the format model is defined by one of the globalization session parameters. Depending on 
the source data type, the parameter name is NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, 

or NLS_TIMESTAMP_TZ_FORMAT. The values of these parameters can be specified in the client environment 
or in an ALTER SESSION statement. 


The dependency of format models on session parameters can have a negative impact on database security when 
conversion without an explicit format model is applied to a datetime value that is being concatenated to text of a 
dynamic SQL statement. Dynamic SQL statements are those statements whose text is concatenated from fragments 
before being passed to a database for execution. Dynamic SQL is frequently associated with the built-in PL/SQL 
package DBMS_SQL or with the PL/SQL statement EXECUTE IMMEDIATE, but these are not the only places 
where dynamically constructed SQL text may be passed as argument. For example: 


EXECUTE IMMEDIATE 
‘SELECT last_name FROM employees WHERE hire_date > " || start_date || ""; 


where start_date has the data type DATE. 


In the above example, the value of start_date is converted to text using a format model specified in the session 
parameter NLS_DATE_FORMAT. The result is concatenated into SQL text. A datetime format model can consist 
simply of literal text enclosed in double quotation marks. Therefore, any user who can explicitly set globalization 
parameters for a session can decide what text is produced by the above conversion. If the SQL statement is 
executed by a PL/SQL procedure, the procedure becomes vulnerable to SQL injection through the session 
parameter. If the procedure runs with definer's rights, with higher privileges than the session itself, the user can 
gain unauthorized access to sensitive data. 


Literals 


The terms literal and constant value are synonymous and refer to a fixed data value. For example, JACK’, 
"BLUE ISLAND’, and '101' are all character literals; 5001 is a numeric literal. Character literals are enclosed in 
single quotation marks so that Oracle can distinguish them from schema object names. 


This section contains these topics: 


Text Literals 
e Numeric Literals 
Datetime Literals 


Interval Literals 


Many SQL statements and functions require you to specify character and numeric literal values. You can also 
specify literals as part of expressions and conditions. You can specify character literals with the ' text ' notation, 
national character literals with the N'text' notation, and numeric literals with the integer , or number notation, 
depending on the context of the literal. The syntactic forms of these notations appear in the sections that follow. 


To specify a datetime or interval data type as a literal, you must take into account any optional precisions included 
in the data types. 


Text Literals 


Use the text literal notation to specify values whenever string appears in the syntax of expressions, conditions, 
SQL functions, and SQL statements in other parts of this reference. This reference uses the terms text literal , 
character literal , and string interchangeably. Text, character, and string literals are always surrounded by single 
quotation marks. If the syntax uses the term char , then you can specify either a text literal or another expression 
that resolves to character data — for example, the last_name column of the hr.employees table. When char 
appears in the syntax, the single quotation marks are not used. 


Text literals have properties of both the CHAR and VARCHAR2 data types: 
- Within expressions and conditions, Oracle treats text literals as though they have the data type CHAR by 
comparing them using blank-padded comparison semantics. 


A text literal can have a maximum length of 4000 bytes if the initialization 
parameter MAX_STRING_SIZE = STANDARD, and 32767 bytes 
if MAX _STRING_SIZE = EXTENDED. 


Here are some valid text literals: 


'Hello' 
'ORACLE.dbs' 
'Jackie"s raincoat' 


'09-MAR-98' 
N'nchar literal’ 


Here are some valid text literals using the alternative quoting mechanism: 


q'!Iname LIKE '%DBMS_%%'!' 

q'<'So,' she said, 'It's finished.'>' 

q'{SELECT * FROM employees WHERE last_name = 'Smith';}' 
ngi Y1234 7' 
q'"name like '[ 


ALI 


Numeric Literals 
Use numeric literal notation to specify fixed and floating-point numbers. 
Integer Literals 


You must use the integer notation to specify an integer whenever integer appears in expressions, conditions, SQL 
functions, and SQL statements described in other parts of this reference. 


An integer can store a maximum of 38 digits of precision. 


Here are some valid integers: 


7 
+255 


NUMBER and Floating-Point Literals 


You must use the number or floating-point notation to specify values whenever number or n appears in 
expressions, conditions, SQL functions, and SQL statements in other parts of this reference. 


A number of type NUMBER can store a maximum of 38 digits of precision. If the literal requires more precision 
than provided by NUMBER, BINARY_FLOAT, or BINARY_DOUBLE, then Oracle truncates the value. If the 
range of the literal exceeds the range supported by NUMBER, BINARY_FLOAT, or BINARY_DOUBLE, then 
Oracle raises an error. 


Numeric literals are SQL syntax elements, which are not sensitive to NLS settings. The decimal separator 
character in numeric literals is always the period (.). However, if a text literal is specified where a numeric value is 
expected, then the text literal is implicitly converted to a number in an NLS-sensitive way. The decimal separator 
contained in the text literal must be the one established with the initialization 

parameter NLS_NUMERIC_CHARACTERS. Oracle recommends that you use numeric literals in SQL scripts to 
make them work independently of the NLS environment. 


The following examples illustrate the behavior of decimal separators in numeric literals and text literals. These 
examples assume that you have established the comma (,) as the NLS decimal separator for the current session 
with the following statement: 


ALTER SESSION SET NLS_NUMERIC_CHARACTERS=",.'; 


The previous statement also establishes the period (.) as the NLS group separator, but that is irrelevant for these 
examples. 


This example uses the required decimal separator (.) in the numeric literal 1.23 and the established NLS decimal 
separator (,) in the text literal '2,34'. The text literal is converted to the numeric value 2.34, and the output is 


displayed using commas for the decimal separators. 


SELECT 2 * 1.23, 3 * '2,34' FROM DUAL; 


2*1.23 3*'2,34' 


The next example shows that a comma is not treated as part of a numeric literal. Rather, the comma is treated as 
the delimiter in a list of two numeric expressions: 2*1 and 23. 


SELECT 2 * 1,23 FROM DUAL; 


The next example shows that the decimal separator in a text literal must match the NLS decimal separator in order 
for implicit text-to-number conversion to succeed. The following statement fails because the decimal separator (.) 
does not match the established NLS decimal separator (,): 


SELECT 3 * '2.34' FROM DUAL; 
ok 

ERROR at line 1: 

ORA-01722: invalid number 


Here are some valid NUMBER literals: 


25 
+6.34 
0.5 
25e-03 
-1 


Here are some valid floating-point number literals: 


25f 
+6.34F 
0.5d 
-1D 


You can also use the following supplied floating-point literals in situations where a value cannot be expressed as a 
numeric literal: 


Floating-Point Literals 


Literal Meaning Example 


Literal Meaning Example 


binary_float_nan A value of 
type BINARY_FLOAT for SELECT COUNT(*) 
which the 
condition IS NAN is true FROM employees 
WHERE 
TO_BINARY_FLOAT(commission_pct) 
!= BINARY_FLOAT_NAN; 
binary_float_infinity Single-precision positive 
infinity SELECT COUNT(*) 
FROM employees 
WHERE salary < 
BINARY_FLOAT_INFINITY; 
binary_double_nan A value of 
type BINARY_DOUBLE for SELECT COUNT(*) 
which the 
condition IS NAN is true FROM employees 
WHERE 
TO_BINARY_FLOAT(commission_pct) 
!= BINARY_FLOAT_NAN; 
binary_double_infinity Double-precision positive 
infinity SELECT COUNT(*) 


FROM employees 


WHERE salary < 
BINARY_DOUBLE_INFINITY; 


Datetime Literals 


Oracle Database supports four datetime data types: DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, 
and TIMESTAMP WITH LOCAL TIME ZONE. 


Date Literals 


You can specify a DATE value as a string literal, or you can convert a character or numeric value to a date value 
with the TO_DATE function. DATE literals are the only case in which Oracle Database accepts 
a TO_DATE expression in place of a string literal. 


To specify a DATE value as a literal, you must use the Gregorian calendar. You can specify an ANSI literal, as 
shown in this example: 


DATE '1998-12-25' 


The ANSI date literal contains no time portion, and must be specified in the format 'YY YY-MM-DD'". 
Alternatively you can specify an Oracle date value, as in the following example: 


TO_DATE('98-DEC-25 17:30',,°Y Y-MON-DD HH24:MI') 


The default date format for an Oracle DATE value is specified by the initialization 
parameter NLS_DATE_FORMAT. This example date format includes a two-digit number for the day of the month, 
an abbreviation of the month name, the last two digits of the year, and a 24-hour time designation. 


Oracle automatically converts character values that are in the default date format into date values when they are 
used in date expressions. 


If you specify a date value without a time component, then the default time is midnight (00:00:00 or 12:00:00 for 
24-hour and 12-hour clock time, respectively). If you specify a date value without a date, then the default date is 
the first day of the current month. 


Oracle DATE columns always contain both the date and time fields. Therefore, if you query a DATE column, then 
you must either specify the time field in your query or ensure that the time fields in the DATE column are set to 
midnight. Otherwise, Oracle may not return the query results you expect. You can use the TRUNC date function to 
set the time field to midnight, or you can include a greater-than or less-than condition in the query instead of an 
equality or inequality condition. 


Here are some examples that assume a table my_table with a number column row_num and 
a DATE column datecol: 


INSERT INTO my_table VALUES (1, SYSDATE); 
INSERT INTO my_table VALUES (2, TRUNC(SYSDATE)); 


SELECT * 
FROM my_table; 


ROW_NUM DATECOL 
1 03-OCT-02 
2 03-OCT-02 


SELECT * 
FROM my_table 
WHERE datecol > TO_DATE('02-OCT-02', 'DD-MON-YY'); 


ROW_NUM DATECOL 


1 03-OCT-02 
2 03-OCT-02 


SELECT * 
FROM my_table 
WHERE datecol = TO_DATE('03-OCT-02',,DD-MON-YY’); 


ROW_NUM DATECOL 


2 03-OCT-02 


If you know that the time fields of your DATE column are set to midnight, then you can query your DATE column 
as shown in the immediately preceding example, or by using the DATE literal: 


SELECT * 
FROM my_table 
WHERE datecol = DATE '2002-10-03'; 


ROW_NUM DATECOL 


2 03-OCT-02 


However, if the DATE column contains values other than midnight, then you must filter out the time fields in the 
query to get the correct result. For example: 


SELECT * 
FROM my_table 
WHERE TRUNC(datecol) = DATE '2002-10-03'; 


ROW_NUM DATECOL 


1 03-OCT-02 
2 03-OCT-02 


Oracle applies the TRUNC function to each row in the query, so performance is better if you ensure the midnight 
value of the time fields in your data. To ensure that the time fields are set to midnight, use one of the following 
methods during inserts and updates: 


Use the TO_DATE function to mask out the time fields: 
INSERT INTO my_table 
VALUES (3, TO_DATE('3-OCT-2002',"DD-MON-YYYY'’)); 
Use the DATE literal: 
INSERT INTO my_table 
VALUES (4, '03-OCT-02'); 
Use the TRUNC function: 


INSERT INTO my_table 
VALUES (5, TRUNC(SYSDATE)); 


The date function SYSDATE returns the current system date and time. The function CURRENT_DATE returns the 
current session date. 


TIMESTAMP Literals 


The TIMESTAMP data type stores year, month, day, hour, minute, and second, and fractional second values. When 
you specify TIMESTAMP as a literal, the fractional_seconds_precision value can be any number of digits up to 
9, as follows: 


TIMESTAMP '1997-01-31 09:26:50.124' 


TIMESTAMP WITH TIME ZONE Literals 


The TIMESTAMP WITH TIME ZONE data type is a variant of TIMESTAMP that includes a time zone region 
name or time zone offset. When you specify TIMESTAMP WITH TIME ZONE as a literal, the 
fractional_seconds_precision value can be any number of digits up to 9. For example: 


TIMESTAMP '1997-01-31 09:26:56.66 +02:00' 


Two TIMESTAMP WITH TIME ZONE values are considered identical if they represent the same instant in UTC, 
regardless of the TIME ZONE offsets stored in the data. For example, 


TIMESTAMP '1999-04-15 8:00:00 -8:00' 


is the same as 


TIMESTAMP '1999-04-15 11:00:00 -5:00' 


8:00 a.m. Pacific Standard Time is the same as 11:00 a.m. Eastern Standard Time. 


You can replace the UTC offset with the TZR (time zone region name) format element. For example, the following 
example has the same value as the preceding example: 


TIMESTAMP '1999-04-15 8:00:00 US/Pacific' 


To eliminate the ambiguity of boundary cases when the daylight saving time switches, use both the TZR anda 
corresponding TZD format element. The following example ensures that the preceding example will return a 
daylight saving time value: 


TIMESTAMP '1999-10-29 01:30:00 US/Pacific PDT' 


You can also express the time zone offset using a datetime expression: 


SELECT TIMESTAMP '2009-10-29 01:30:00' AT TIME ZONE 'US/Pacific' 
FROM DUAL; 


TIMESTAMP WITH LOCAL TIME ZONE Literals 


The TIMESTAMP WITH LOCAL TIME ZONE data type differs from TIMESTAMP WITH TIME ZONE in that 
data stored in the database is normalized to the database time zone. The time zone offset is not stored as part of the 
column data. There is no literal for TIMESTAMP WITH LOCAL TIME ZONE. Rather, you represent values of 
this data type using any of the other valid datetime literals. The table that follows shows some of the formats you 
can use to insert a value into a TIMESTAMP WITH LOCAL TIME ZONE column, along with the corresponding 
value returned by a query. 


TIMESTAMP WITH LOCAL TIME ZONE Literals 


Value Specified in INSERT Statement Value Returned by Query 


'19-FEB-2004' 19-FEB-2004.00.00.000000 AM 
SYSTIMESTAMP 19-FEB-04 02.54.36.497659 PM 
TO_TIMESTAMP('19-FEB-2004', 'DD-MON-YYYY') 19-FEB-04 12.00.00.000000 AM 
SYSDATE 19-FEB-04 02.55.29.000000 PM 
TO_DATE(‘19-FEB-2004', 'DD-MON-YYYY') 19-FEB-04 12.00.00.000000 AM 
TIMESTAMP'2004-02-19 8:00:00 US/Pacific' 19-FEB-04 08.00.00.000000 AM 


Notice that if the value specified does not include a time component (either explicitly or implicitly), then the value 
returned defaults to midnight. 


Interval Literals 


An interval literal specifies a period of time. You can specify these differences in terms of years and months, or in 
terms of days, hours, minutes, and seconds. Oracle Database supports two types of interval 

literals, YEAR TO MONTH and DAY TO SECOND. Each type contains a leading field and may contain a trailing 
field. The leading field defines the basic unit of date or time being measured. The trailing field defines the smallest 
increment of the basic unit being considered. For example, aYEAR TO MONTH interval considers an interval of 
years to the nearest month. A DAY TO MINUTE interval considers an interval of days to the nearest minute. 


If you have date data in numeric form, then you can use 
the NUMTOYMINTERVAL or NUMTODSINTERVAL conversion function to convert the numeric data into 
interval values. 


INTERVAL YEAR TO MONTH 


If you specify a trailing field, then it must be less significant than the leading field. For example, INTERVAL '0- 
1' MONTH TO YEAR is not valid. 


The following INTERVAL YEAR TO MONTH literal indicates an interval of 123 years, 2 months: 


INTERVAL '123-2' YEAR(3) TO MONTH 


Examples of the other forms of the literal follow, including some abbreviated versions: 


Forms of INTERVAL YEAR TO MONTH Literals 


Form of Interval Literal Interpretation 

INTERVAL '123-2' YEAR(3) TO MONTH An interval of 123 years, 2 months. You must specify 
the leading field precision if it is greater than the 
default of 2 digits. 

INTERVAL '123' YEAR(3) An interval of 123 years 0 months. 

INTERVAL '300' MONTH(3) An interval of 300 months. 

INTERVAL '4' YEAR Maps to INTERVAL '4-0' YEAR TO MONTH and 


indicates 4 years. 


Form of Interval Literal 


INTERVAL '50' MONTH 


INTERVAL '123' YEAR 


Interpretation 


Maps to INTERVAL '4-2' YEAR TO MONTH and 
indicates 50 months or 4 years 2 months. 


Returns an error, because the default precision is 2, 
and '123' has 3 digits. 


You can add or subtract one INTERVAL YEAR TO MONTH literal to or from another to yield 
another INTERVAL YEAR TO MONTH literal. For example: 


INTERVAL '5-3' YEAR TO MONTH + INTERVAL'20' MONTH = 


INTERVAL '6-11' YEAR TO MONTH 


INTERVAL DAY TO SECOND 


If you specify a trailing field, then it must be less significant than the leading field. For 
example, INTERVAL MINUTE TO DAY is not valid. As a result of this restriction, if SECOND is the leading 


field, the interval literal cannot have any trailing field. 


The valid range of values for the trailing field are as follows: 


HOUR: 0 to 23 
MINUTE: 0 to 59 
«+ SECOND: 0 to 59.999999999 


Examples of the various forms of INTERVAL DAY TO SECOND literals follow, including some abbreviated 


versions: 


Forms of INTERVAL DAY TO SECOND Literals 
Form of Interval Literal 


INTERVAL '4 5:12:10.222' DAY TO SECOND(3) 


INTERVAL '4 5:12' DAY TO MINUTE 
INTERVAL '400 5' DAY(3) TO HOUR 
INTERVAL '400' DAY(3) 


INTERVAL '11:12:10.2222222' HOUR TO 
SECOND(7) 


INTERVAL '11:20' HOUR TO MINUTE 
INTERVAL '10' HOUR 

INTERVAL '10:22' MINUTE TO SECOND 
INTERVAL '10' MINUTE 


INTERVAL '4' DAY 


INTERVAL '25' HOUR 


Interpretation 


4 days, 5 hours, 12 minutes, 10 seconds, and 222 
thousandths of a second. 


4 days, 5 hours and 12 minutes. 
400 days 5 hours. 
400 days. 


11 hours, 12 minutes, and 10.2222222 seconds. 


11 hours and 20 minutes. 
10 hours. 

10 minutes 22 seconds. 
10 minutes. 

4 days. 


25 hours. 


Form of Interval Literal Interpretation 


INTERVAL '40' MINUTE AO minutes. 
INTERVAL '120' HOUR(3) 120 hours. 
INTERVAL '30.12345' SECOND(2,4) 30.1235 seconds. The fractional second '12345' is 


rounded to '1235' because the precision is 4. 


You can add or subtract one DAY TO SECOND interval literal from another DAY TO SECOND literal. For 
example. 


INTERVAL'20' DAY - INTERVAL'240' HOUR = INTERVAL'10-0' DAY TO SECOND 


Nulls 


If a column in a row has no value, then the column is said to be null , or to contain null. Nulls can appear in 
columns of any data type that are not restricted by NOT NULL or PRIMARY KEY integrity constraints. Use a null 
when the actual value is not known or when a value would not be meaningful. 


Oracle Database treats a character value with a length of zero as null. However, do not use null to represent a 
numeric value of zero, because they are not equivalent. 


Note: 


Oracle Database currently treats a character value with a length of zero as null. However, this may not continue to 
be true in future releases, and Oracle recommends that you do not treat empty strings the same as nulls. 


Any arithmetic expression containing a null always evaluates to null. For example, null added to 10 is null. In fact, 
all operators (except concatenation) return null when given a null operand. 


Nulls with Comparison Conditions 


To test for nulls, use only the comparison conditions IS NULL and IS NOT NULL. If you use any other condition 
with nulls and the result depends on the value of the null, then the result is UNKNOWN. Because null represents a 
lack of data, a null cannot be equal or unequal to any value or to another null. However, Oracle considers two nulls 
to be equal when evaluating a DECODE function. 


Oracle also considers two nulls to be equal if they appear in compound keys. That is, Oracle considers identical 
two compound keys containing nulls if all the non-null components of the keys are equal. 


Nulls in Conditions 


A condition that evaluates to UNKNOWN acts almost like FALSE. For example, a SELECT statement with a 
condition in the WHERE clause that evaluates to UNKNOWN returns no rows. However, a condition evaluating 
to UNKNOWN differs from FALSE in that further operations on an UNKNOWN condition evaluation will 
evaluate to UNKNOWN. Thus, NOT FALSE evaluates to TRUE, but NOT UNKNOWN evaluates 

to UNKNOWN. 


Conditions Containing Nulls 
Condition Value of A Evaluation 
a IS NULL 10 FALSE 


a IS NOT NULL 10 TRUE 


Condition Value of A Evaluation 


a IS NULL NULL TRUE 

a IS NOT NULL NULL FALSE 

a = NULL 10 UNKNOWN 
a != NULL 10 UNKNOWN 
a = NULL NULL UNKNOWN 
a != NULL NULL UNKNOWN 
a=10 NULL UNKNOWN 
a!=10 NULL UNKNOWN 

Comments 


You can create two types of comments: 


Comments within SQL statements are stored as part of the application code that executes the SQL 
statements. 


Comments associated with individual schema or nonschema objects are stored in the data dictionary along 
with metadata on the objects themselves. 


Comments Within SQL Statements 


Comments can make your application easier for you to read and maintain. For example, you can include a 
comment in a statement that describes the purpose of the statement within your application. With the exception of 
hints, comments within SQL statements do not affect the statement execution. 


A comment can appear between any keywords, parameters, or punctuation marks in a statement. You can include a 
comment in a statement in two ways: 


- Begin the comment with a slash and an asterisk (/*). Proceed with the text of the comment. This text can 
span multiple lines. End the comment with an asterisk and a slash (*/). The opening and terminating 
characters need not be separated from the text by a space or a line break. 


Begin the comment with -- (two hyphens). Proceed with the text of the comment. This text cannot extend 
to a new line. End the comment with a line break. 


Some of the tools used to enter SQL have additional restrictions. For example, if you are using SQL*Plus, by 
default you cannot have a blank line inside a multiline comment. For more information, refer to the documentation 
for the tool you use as an interface to the database. 


A SQL statement can contain multiple comments of both styles. The text of a comment can contain any printable 
characters in your database character set. 


Example 


These statements contain many comments: 


SELECT last_name, employee_id, salary + NVL(commission_pct, 0), 
job_id, e.department_id 
/* Select all employees whose compensation is 
greater than that of Pataballa.*/ 
FROM employees e, departments d 


/*The DEPARTMENTS table is used to get the department name.*/ 
WHERE e.department_id = d.department_id 
AND salary + NVL(commission_pct,0) > /* Subquery: Si 
(SELECT salary + NVL(commission_pct,0) 
/* total compensation is salary + commission_pct */ 
FROM employees 
WHERE last_name = 'Pataballa’) 
ORDER BY last_name, employee_id; 


SELECT last_name, -- select the name 
employee_id -- employee id 
salary + NVL(commission_pct, 0), -- total compensation 
job_id, -- job 
e.department_id -- and department 
FROM employees e, -- of all employees 


departments d 
WHERE e.department_id = d.department_id 
AND salary + NVL(commission_pct, 0) > -- whose compensation 
-- is greater than 
(SELECT salary + NVL(commission_pct,0) -- the compensation 
FROM employees 


WHERE last_name = 'Pataballa’) -- of Pataballa 
ORDER BY last_name -- and order by last name 
employee_id -- and employee id. 


Comments on Schema and Nonschema Objects 


You can use the COMMENT command to associate a comment with a schema object (table, view, materialized 
view, operator, indextype, mining model) or a nonschema object (edition) using the COMMENT command. You 
can also create a comment on a column, which is part of a table schema object. Comments associated with schema 
and nonschema objects are stored in the data dictionary. 


Hints 


Hints are comments in a SQL statement that pass instructions to the Oracle Database optimizer. The optimizer uses 
these hints to choose an execution plan for the statement, unless some condition exists that prevents the optimizer 
from doing so. 


Hints were introduced in Oracle7, when users had little recourse if the optimizer generated suboptimal plans. Now 
Oracle provides a number of tools, including the SQL Tuning Advisor, SQL plan management, and SQL 
Performance Analyzer, to help you address performance problems that are not solved by the optimizer. Oracle 
strongly recommends that you use those tools rather than hints. The tools are far superior to hints, because when 
used on an ongoing basis, they provide fresh solutions as your data and database environment change. 


Hints should be used sparingly, and only after you have collected statistics on the relevant tables and evaluated the 
optimizer plan without hints using the EXPLAIN PLAN statement. Changing database conditions as well as query 
performance enhancements in subsequent releases can have significant impact on how hints in your code affect 
performance. 


The remainder of this section provides information on some commonly used hints. If you decide to use hints rather 
than the more advanced tuning tools, be aware that any short-term benefit resulting from the use of hints may not 
continue to result in improved performance over the long term. 


Using Hints 


A statement block can have only one comment containing hints, and that comment must follow 
the SELECT, UPDATE, INSERT, MERGE, or DELETE keyword. 


Oracle Database ignores hints and does not return an error under the following circumstances: 


- The hint contains misspellings or syntax errors. However, the database does consider other correctly 
specified hints in the same comment. 


The comment containing the hint does not follow a DELETE, INSERT, MERGE, SELECT, 
or UPDATE keyword. 


- A combination of hints conflict with each other. However, the database does consider other hints in the 
same comment. 


The database environment uses PL/SQL version 1, such as Forms version 3 triggers, Oracle Forms 4.5, 
and Oracle Reports 2.5. 


- A global hint refers to multiple query blocks. 
With 19c you can use DBMS_XPLAN to find out whether a hint is used or not used. 
Specifying a Query Block in a Hint 


You can specify an optional query block name in many hints to specify the query block to which the hint applies. 
This syntax lets you specify in the outer query a hint that applies to an inline view. 


The syntax of the query block argument is of the form @ queryblock , where queryblock is an identifier that 
specifies a query block in the query. The queryblock identifier can either be system-generated or user-specified. 
When you specify a hint in the query block itself to which the hint applies, you omit the @queryblock syntax. 


The system-generated identifier can be obtained by using EXPLAIN PLAN for the query. 
Pretransformation query block names can be determined by running EXPLAIN PLAN for the query using 
the NO_QUERY_TRANSFORMATION hint. 


- The user-specified name can be set with the QB_NAME hint. 
Specifying Multiple Query Blocks in a Global Hint 


Oracle Database ignores global hints that refer to multiple query blocks. To avoid this issue, Oracle recommends 
that you specify the object alias in the hint instead of using tablespec and indexspec . 


For example, consider the following view v and table t: 


CREATE VIEW v AS 
SELECT e.last_name, e.department_id, d.location_id 
FROM employees e, departments d 
WHERE e.department_id = d.department_id; 


CREATE TABLE t AS 
SELECT * from employees 
WHERE employee_id < 200; 


The LEADING hint is ignored in the following query because it refers to multiple query blocks, that is, the main 
query block containing table t and the view query block v: 


EXPLAIN PLAN 
SET STATEMENT_ID = 'Test 1' 
INTO plan_table FOR 
(SELECT /*+ LEADING(v.e v.d t) */ * 
FROM t, v 
WHERE t.department_id = v.department_id); 


The following SELECT statement returns the execution plan, which shows that the LEADING hint was ignored: 


SELECT id, LPAD(' ',2*(LEVEL-1))||operation operation, options, object_name, object_alias 
FROM plan_table 
START WITH id = 0 AND statement_id = 'Test 1' 
CONNECT BY PRIOR id = parent_id AND statement_id = "Test 1' 
ORDER BY id; 


ID OPERATION OPTIONS OBJECT_NAME OBJECT_ALIAS 
0 SELECT STATEMENT 
1 HASH JOIN 
2 HASH JOIN 
3 TABLE ACCESS FULL DEPARTMENTS D@SEL$2 
4 TABLE ACCESS FULL EMPLOYEES E@SEL$2 
5 TABLE ACCESS FULL T T@SEL$1 


The LEADING hint is honored in the following query because it refers to object aliases, which can be found in the 
execution plan that was returned by the previous query: 


EXPLAIN PLAN 
SET STATEMENT_ID = 'Test 2' 
INTO plan_table FOR 
(SELECT /*+ LEADING(E@SEL$2 D@SEL$2 T@SEL$1) */ * 
FROM t, v 
WHERE t.department_id = v.department_id); 


The following SELECT statement returns the execution plan, which shows that the LEADING hint was honored: 


SELECT id, LPAD(' ',2*(LEVEL-1))||operation operation, options, 
object_name, object_alias 
FROM plan_table 
START WITH id = 0 AND statement_id = 'Test 2' 
CONNECT BY PRIOR id = parent_id AND statement_id = "Test 2' 
ORDER BY id; 


ID OPERATION OPTIONS OBJECT_NAME OBJECT_ALIAS 
0 SELECT STATEMENT 
1 HASH JOIN 
2 HASH JOIN 
3 TABLE ACCESS FULL EMPLOYEES E@SEL$2 
4 TABLE ACCESS FULL DEPARTMENTS D@SEL$2 
5 TABLE ACCESS FULL T T@SEL$1 


Alphabetical Listing of Hints 


The ALL_ROWS hint instructs the optimizer to optimize a statement block with a goal of best throughput, which 
is minimum total resource consumption. For example, the optimizer uses the query optimization approach to 
optimize this statement for best throughput: 


SELECT /*+ ALL_ROWS */ employee_id, last_name, salary, job_id 
FROM employees 
WHERE employee_id = 107; 


If you specify either the ALL_ROWS or the FIRST_ROWS hint in a SQL statement, and if the data dictionary 
does not have statistics about tables accessed by the statement, then the optimizer uses default statistical values, 
such as allocated storage for such tables, to estimate the missing statistics and to subsequently choose an execution 
plan. These estimates might not be as accurate as those gathered by the DBMS_STATS package, so you should use 
the DBMS_STATS package to gather statistics. 


If you specify hints for access paths or join operations along with either the ALL_ROWS or FIRST_ROWS hint, 
then the optimizer gives precedence to the access paths and join operations specified by the hints. 


Database Objects 


Oracle Database recognizes objects that are associated with a particular schema and objects that are not associated 
with any particular schema, as described in the sections that follow. 


Schema Objects 


A schema is a collection of logical structures of data, or schema objects. A schema is owned by a database user 
and has the same name as that user. Each user owns a single schema. Schema objects can be created and 
manipulated with SQL and include the following types of objects: 


- Analytic views 

- Attribute dimensions 
Clusters 
Constraints 
Database links 
Database triggers 
Dimensions 
External procedure libraries 
Hierarchies 
Index-organized tables 

- Indexes 

- Indextypes 

- Java classes 

e Java resources 
Java sources 
Join groups 
Materialized views 
Materialized view logs 
Mining models 
Object tables 
Object types 
Object views 

e Operators 

- Packages 

- Sequences 

- Stored functions 
Stored procedures 
Synonyms 
Tables 
Views 
Zone maps 


Nonschema Objects 


Other types of objects are also stored in the database and can be created and manipulated with SQL but are not 
contained in a schema: 


Contexts 
Directories 
Editions 

Flashback archives 
Lockdown profiles 


Profiles 
- Restore points 
e Roles 


- Rollback segments 

- Tablespaces 
Tablespace sets 
Unified audit policies 
Users 


In this reference, each type of object is described in the section devoted to the statement that creates the database 
object. These statements begin with the keyword CREATE. 


Pseudocolumns 


A pseudocolumn behaves like a table column, but is not actually stored in the table. You can select from 
pseudocolumns, but you cannot insert, update, or delete their values. A pseudocolumn is also similar to a function 
without arguments. However, functions without arguments typically return the same value for every row in the 
result set, whereas pseudocolumns typically return a different value for each row. 


This chapter contains the following sections: 


Hierarchical Query Pseudocolumns 
Sequence Pseudocolumns 
Version Query Pseudocolumns 

« COLUMN_VALUE Pseudocolumn 
OBJECT_ID Pseudocolumn 
OBJECT_VALUE Pseudocolumn 

- ORA ROWSCN Pseudocolumn 
ROWID Pseudocolumn 
ROWNUM Pseudocolumn 

e XMLDATA Pseudocolumn 


Hierarchical Query Pseudocolumns 


The hierarchical query pseudocolumns are valid only in hierarchical queries. The hierarchical query 
pseudocolumns are: 


CONNECT_BY_ISCYCLE Pseudocolumn 
CONNECT_BY_ISLEAF Pseudocolumn 
- LEVEL Pseudocolumn 


To define a hierarchical relationship in a query, you must use the CONNECT BY clause. 


CONNECT_BY_ISCYCLE Pseudocolumn 


The CONNECT_BY_ISCYCLE pseudocolumn returns 1 if the current row has a child which is also its ancestor. 
Otherwise it returns 0. 


You can specify CONNECT_BY_ISCYCLE only if you have specified the NOCYCLE parameter of 
the CONNECT BY clause. NOCYCLE enables Oracle to return the results of a query that would otherwise fail 
because of a CONNECT BY loop in the data. 


CONNECT_BY_ISLEAF Pseudocolumn 


The CONNECT_BY_ISLEAF pseudocolumn returns 1 if the current row is a leaf of the tree defined by 
the CONNECT BY condition. Otherwise it returns 0. This information indicates whether a given row can be 
further expanded to show more of the hierarchy. 


CONNECT_BY_ISLEAF Example 


The following example shows the first three levels of the hr.employees table, indicating for each row whether it is 
a leaf row (indicated by 1 in the IsLeaf column) or whether it has child rows (indicated by 0 in the IsLeaf column): 


SELECT last_name "Employee", CONNECT_BY_ISLEAF "IsLeaf", 
LEVEL, SYS_CONNECT_BY_PATH(last_name, '/') "Path" 
FROM employees 
WHERE LEVEL <= 3 AND department_id = 80 
START WITH employee_id = 100 
CONNECT BY PRIOR employee_id = manager_id AND LEVEL <= 4 
ORDER BY "Employee", "IsLeaf"; 


Employee IsLeaf LEVEL Path 
Abel 1 3 /King/Zlotkey/Abel 
Ande 1 3 /King/Errazuriz/Ande 
Banda 1 3 /King/Errazuriz/Banda 
Bates 1 3 /King/Cambrault/Bates 
Bernstein 1 3 /King/Russell/Bernstein 
Bloom 1 3 /King/Cambrault/Bloom 
Cambrault 0 2 /King/Cambrault 
Cambrault 1 3 /King/Russell/Cambrault 
Doran 1 3 /King/Partners/Doran 
Errazuriz 0 2 /King/Errazuriz 
Fox 1 3 /King/Cambrault/Fox 
LEVEL Pseudocolumn 


For each row returned by a hierarchical query, the LEVEL pseudocolumn returns 1 for a root row, 2 for a child of a 
root, and so on. A root row is the highest row within an inverted tree. A child row is any nonroot row. A 
parent row is any row that has children. A leaf row is any row without children. 


Figure 3-1 Hierarchical Tree 


Level 1 


Level 2 pereny 
child/ parent/ 
Level 4 


Sequence Pseudocolumns 


A sequence is a schema object that can generate unique sequential values. These values are often used for 
primary and unique keys. You can refer to sequence values in SQL statements with these pseudocolumns: 


e CURRVAL: Returns the current value of a sequence 
NEXTVAL: Increments the sequence and returns the next value 


You must qualify CURRVAL and NEXTVAL with the name of the sequence: 


sequence .CURRVAL 
sequence .NEXTVAL 


To refer to the current or next value of a sequence in the schema of another user, you must have been granted 
either SELECT object privilege on the sequence or SELECT ANY SEQUENCE system privilege, and you must 
qualify the sequence with the schema containing it: 


schema . sequence .CURRVAL 
schema . sequence .NEXTVAL 


To refer to the value of a sequence on a remote database, you must qualify the sequence with a complete or partial 
name of a database link: 


schema . sequence .CURRVAL@ dblink 
schema . sequence .NEXTVAL@ dblink 


A sequence can be accessed by many users concurrently with no waiting or locking. 


Where to Use Sequence Values 

You can use CURRVAL and NEXTVAL in the following locations: 
The select list of a SELECT statement that is not contained in a subquery, materialized view, or view 
The select list of a subquery in an INSERT statement 


- The VALUES clause of an INSERT statement 
The SET clause of an UPDATE statement 


Within a single SQL statement that uses CURRVAL or NEXTVAL, all referenced LONG columns, updated tables, 
and locked tables must be located on the same database. 


How to Use Sequence Values 


When you create a sequence, you can define its initial value and the increment between its values. The first 
reference to NEXTVAL returns the initial value of the sequence. Subsequent references to NEXTVAL increment 
the sequence value by the defined increment and return the new value. Any reference to CURRVAL always returns 
the current value of the sequence, which is the value returned by the last reference to NEXTVAL. 


Before you use CURRVAL for a sequence in your session, you must first initialize the sequence with NEXTVAL. 
Within a single SQL statement containing a reference to NEXTVAL, Oracle increments the sequence once: 


For each row returned by the outer query block of a SELECT statement. Such a query block can appear in 
the following places: 
o A top-level SELECT statement 


o An INSERT ... SELECT statement (either single-table or multitable). For a multitable insert, the 
reference to NEXTVAL must appear in the VALUES clause, and the sequence is updated once for 
each row returned by the subquery, even though NEXTVAL may be referenced in multiple 
branches of the multitable insert. 


o A CREATE TABLE ... AS SELECT statement 
o ACREATE MATERIALIZED VIEW ... AS SELECT statement 
For each row updated in an UPDATE statement 
For each INSERT statement containing a VALUES clause 
- For each INSERT ... [ALL | FIRST] statement (multitable insert). A multitable insert is considered a single 
SQL statement. Therefore, a reference to the NEXTVAL of a sequence will increase the sequence only 
once for each input record coming from the SELECT portion of the statement. If NEXTVAL is specified 


more than once in any part of the INSERT ... [ALL | FIRST ] statement, then the value will be the same for 
all insert branches, regardless of how often a given record might be inserted. 


For each row merged by a MERGE statement. The reference to NEXTVAL can appear in the 
merge_insert_clause or the merge_update_clause or both. The NEXTVALUE value is incremented for 
each row updated and for each row inserted, even if the sequence number is not actually used in the update 
or insert operation. If NEXTVAL is specified more than once in any of these locations, then the sequence 
is incremented once for each row and returns the same value for all occurrences of NEXTVAL for that 
row. 


For each input row in a multitable INSERT ALL statement. NEXTVAL is incremented once for each row 
returned by the subquery, regardless of how many occurrences of the insert_into_clause map to each row. 


If any of these locations contains more than one reference to NEXTVAL, then Oracle increments the sequence 
once and returns the same value for all occurrences of NEXTVAL. 


If any of these locations contains references to both CURRVAL and NEXTVAL, then Oracle increments the 
sequence and returns the same value for both CURRVAL and NEXTVAL. 


Finding the next value of a sequence: Example 


This example selects the next value of the employee sequence in the sample schema hr: 


SELECT employees_seq.nextval 
FROM DUAL; 


Inserting sequence values into a table: Example 


This example increments the employee sequence and uses its value for a new employee inserted into the sample 
table hr.employees: 


INSERT INTO employees 
VALUES (employees_seq.nextval, John’, 'Doe', ‘jdoe', '555-1212', 
TO_DATE(SYSDATE), 'PU_CLERK'’, 2500, null, null, 30); 


Reusing the current value of a sequence: Example 


This example adds a new order with the next order number to the master order table. It then adds suborders with 
this number to the detail order table: 


INSERT INTO orders (order_id, order_date, customer_id) 
VALUES (orders_seq.nextval, TO_DATE(SYSDATE), 106); 


INSERT INTO order_items (order_id, line_item_id, product_id) 
VALUES (orders_seq.currval, 1, 2359); 


INSERT INTO order_items (order_id, line_item_id, product_id) 
VALUES (orders_seq.currval, 2, 3290); 


INSERT INTO order_items (order_id, line_item_id, product_id) 
VALUES (orders_seq.currval, 3, 2381); 


Version Query Pseudocolumns 


The version query pseudocolumns are valid only in Oracle Flashback Version Query, which is a form of Oracle 
Flashback Query. The version query pseudocolumns are: 


VERSIONS_STARTSCN and VERSIONS_STARTTIME: Starting System Change Number (SCN) 

or TIMESTAMP when the row version was created. This pseudocolumn identifies the time when the data 
first had the values reflected in the row version. Use this pseudocolumn to identify the past target time for 
Oracle Flashback Table or Oracle Flashback Query. If this pseudocolumn is NULL, then the row version 
was created before start. 


- VERSIONS_ENDSCN and VERSIONS_ENDTIME: SCN or TIMESTAMP when the row version 
expired. If the pseudocolumn is NULL, then either the row version was current at the time of the query or 
the row corresponds to a DELETE operation. 


VERSIONS_XID: Identifier (a RAW number) of the transaction that created the row version. 


VERSIONS_OPERATION: Operation performed by the transaction: | for insertion, D for deletion, 
or U for update. The version is that of the row that was inserted, deleted, or updated; that is, the row after 
an INSERT operation, the row before a DELETE operation, or the row affected by an UPDATE operation. 


For user updates of an index key, Oracle Flashback Version Query might treat an UPDATE operation as 
two operations, DELETE plus INSERT, represented as two version rows with a D followed by 
an I VERSIONS_OPERATION. 


COLUMN_VALUE Pseudocolumn 


When you refer to an XMLTable construct without the COLUMNS clause, or when you use the TABLE collection 
expression to refer to a scalar nested table type, the database returns a virtual table with a single column. This 
name of this pseudocolumn is COLUMN_VALUE. 


In the context of XMLTable, the value returned is of data type XMLType. For example, the following two 
statements are equivalent, and the output for both shows COLUMN_VALUE as the name of the column being 
returned: 


SELECT * 
FROM XMLTABLE(‘<a>123</a>'); 


COLUMN_VALUE 


<a>123</a> 


SELECT COLUMN_VALUE 
FROM (XMLTable('<a>123</a>')); 


COLUMN_VALUE 


<a>123</a> 


In the context of a TABLE collection expression, the value returned is the data type of the collection element. The 
following statements create the two levels of nested tables to show the uses of COLUMN_VALUE in this context: 


CREATE TYPE phone AS TABLE OF NUMBER; 
/ 
CREATE TYPE phone_list AS TABLE OF phone; 
/ 


The next statement uses COLUMN_VALUE to select from the phone type: 


SELECT t.COLUMN_VALUE 
FROM TABLE(phone(1,2,3)) t; 


COLUMN_VALUE 


In a nested type, you can use the COLUMN_VALUE pseudocolumn in both the select list and 
the TABLE collection expression: 


SELECT t.COLUMN_VALUE 
FROM TABLE(phone_list(phone(1,2,3))) p, TABLE(p. COLUMN_VALUE) t; 


COLUMN_VALUE 


The keyword COLUMN_VALUE is also the name that Oracle Database generates for the scalar value of an inner 
nested table without a column or attribute name, as shown in the example that follows. In this 
context, COLUMN_VALUE is not a pseudocolumn, but an actual column name. 


CREATE TABLE my_customers ( 
cust_id NUMBER, 


name VARCHAR2(25), 

phone_numbers phone list, 

credit_limit NUMBER) 
NESTED TABLE phone_numbers STORE AS outer_ntab 
(NESTED TABLE COLUMN_VALUE STORE AS inner_ntab); 


OBJECT_ID Pseudocolumn 


The OBJECT_ID pseudocolumn returns the object identifier of a column of an object table or view. Oracle uses 
this pseudocolumn as the primary key of an object table. OBJECT_ID is useful in INSTEAD OF triggers on views 
and for identifying the ID of a substitutable row in an object table. 


OBJECT_VALUE Pseudocolumn 


The OBJECT_VALUE pseudocolumn returns system-generated names for the columns of an object 
table, XMLType table, object view, or XMLType view. This pseudocolumn is useful for identifying the value of a 
substitutable row in an object table and for creating object views with the WITH OBJECT IDENTIFIER clause. 


ORA_ROWSCN Pseudocolumn 


ORA_ROWSCN reflects the system change-number (SCN) of the most recent change to a row. This change can be 
at the level of a block (coarse) or at the level of a row (fine-grained). The latter is provided by row-level 
dependency tracking. In the absence of row-level dependencies, ORA_ROWSCN reflects block-level 
dependencies. 


Whether at the block level or at the row level, the ORA_ROWSCN should not be considered to be an exact SCN. 
For example, if a transaction changed row R in a block and committed at SCN 10, it is not always true that 

the ORA_ROWSCN for the row would return 10. While a value less than 10 would never be returned, any value 
greater than or equal to 10 could be returned. That is, the ORA_ROWSCN of a row is not always guaranteed to be 
the exact commit SCN of the transaction that last modified that row. However, with fine-grained ORA_ROWSCN, 
if two transactions T1 and T2 modified the same row R, one after another, and committed, a query on 

the ORA_-ROWSCN of row R after the commit of T1 will return a value lower than the value returned after the 
commit of T2. If a block is queried twice, then it is possible for the value of ORA_ROWSCN to change between 
the queries even though rows have not been updated in the time between the queries. The only guarantee is that the 
value of ORA_ROWSCN in both queries is greater than the commit SCN of the transaction that last modified that 
row. 


You cannot use the ORA_ROWSCN pseudocolumn in a query to a view. However, you can use it to refer to the 
underlying table when creating a view. You can also use this pseudocolumn in the WHERE clause of 
an UPDATE or DELETE statement. 


ORA_ROWSCN is not supported for Flashback Query. Instead, use the version query pseudocolumns, which are 
provided explicitly for Flashback Query. 


Restriction on ORA_ROWSCN: This pseudocolumn is not supported for external tables. 
Example 


The first statement below uses the ORA_ROWSCN pseudocolumn to get the system change number of the last 
operation on the employees table. The second statement uses the pseudocolumn with 
the SCN_TO_TIMESTAMP function to determine the timestamp of the operation: 


SELECT ORA_ROWSCN, last_name 
FROM employees 
WHERE employee_id = 188; 


SELECT SCN_TO_TIMESTAMP(ORA_ROWSCN), last_name 
FROM employees 
WHERE employee_id = 188; 


ROWID Pseudocolumn 


For each row in the database, the ROWID pseudocolumn returns the address of the row. Oracle Database rowid 
values contain information necessary to locate a row: 
The data object number of the object 
- The data block in the data file in which the row resides 
The position of the row in the data block (first row is 0) 
- The data file in which the row resides (first file is 1). The file number is relative to the tablespace. 


Usually, a rowid value uniquely identifies a row in the database. However, rows in different tables that are stored 
together in the same cluster can have the same rowid. 


Values of the ROWID pseudocolumn have the data type ROWID or UROWID. 
Rowid values have several important uses: 


They are the fastest way to access a single row. 
They can show you how the rows in a table are stored. 


- They are unique identifiers for rows in a table. 


You should not use ROWID as the primary key of a table. If you delete and reinsert a row with the Import and 
Export utilities, for example, then its rowid may change. If you delete a row, then Oracle may reassign its rowid to 
a new row inserted later. 


Although you can use the ROWID pseudocolumn in the SELECT and WHERE clause of a query, these 
pseudocolumn values are not actually stored in the database. You cannot insert, update, or delete a value of 
the ROWID pseudocolumn. 


Example 


This statement selects the address of all rows that contain data for employees in department 20: 


SELECT ROWID, last_name 
FROM employees 
WHERE department_id = 20; 


ROWNUM Pseudocolumn 


For each row returned by a query, the ROWNUM pseudocolumn returns a number indicating the order in which 
Oracle selects the row from a table or set of joined rows. The first row selected has a ROWNUM of 1, the second 
has 2, and so on. 


You can use ROWNUM to limit the number of rows returned by a query, as in this example: 


SELECT * 
FROM employees 
WHERE ROWNUM < 11; 


If an ORDER BY clause follows ROWNUM in the same query, then the rows will be reordered by 

the ORDER BY clause. The results can vary depending on the way the rows are accessed. For example, if 

the ORDER BY clause causes Oracle to use an index to access the data, then Oracle may retrieve the rows ina 
different order than without the index. Therefore, the following statement does not necessarily return the same 
rows as the preceding example: 


SELECT * 
FROM employees 
WHERE ROWNUM < 11 
ORDER BY last_name; 


If you embed the ORDER BY clause in a subquery and place the ROWNUM condition in the top-level query, then 
you can force the ROWNUM condition to be applied after the ordering of the rows. For example, the following 
query returns the employees with the 10 smallest employee numbers. This is sometimes referred to as top-N 
reporting : 


SELECT * 
FROM (SELECT * FROM employees ORDER BY employee_id) 
WHERE ROWNUM < 11; 


In the preceding example, the ROWNUM values are those of the top-level SELECT statement, so they are 
generated after the rows have already been ordered by employee_id in the subquery. 


Conditions testing for ROWNUM values greater than a positive integer are always false. For example, this query 
returns no rows: 


SELECT * 
FROM employees 
WHERE ROWNUM > 1; 


The first row fetched is assigned a ROWNUM of 1 and makes the condition false. The second row to be fetched is 
now the first row and is also assigned aROWNUM of 1 and makes the condition false. All rows subsequently fail 
to satisfy the condition, so no rows are returned. 


You can also use ROWNUM to assign unique values to each row of a table, as in this example: 


UPDATE my_table 
SET columni = ROWNUM; 


XMLDATA Pseudocolumn 


Oracle stores XMLType data either in LOB or object-relational columns, based on XMLSchema information and 
how you specify the storage clause. The XMLDATA pseudocolumn lets you access the underlying LOB or object 
relational column to specify additional storage clause parameters, constraints, indexes, and so forth. 


Example 


The following statements illustrate the use of this pseudocolumn. Suppose you create a simple table 
of XMLType with one CLOB column: 


CREATE TABLE xml_lob_tab of XMLTYPE 
XMLTYPE STORE AS CLOB; 


To change the storage characteristics of the underlying LOB column, you can use the following statement: 


ALTER TABLE xml_lob_tab 
MODIFY LOB (XMLDATA) (STORAGE (MAXSIZE 2G) CACHE); 


Now suppose you have created an XMLSchema-based table like the xwarehouses table. You could then use 
the XMLDATA column to set the properties of the underlying columns, as shown in the following statement: 


ALTER TABLE xwarehouses 
ADD (UNIQUE(XMLDATA."Warehouseld")); 
Operators 


An operator manipulates data items and returns a result. Syntactically, an operator appears before or after an 
operand or between two operands. 


This chapter contains these sections: 

e SQL Operators 
Arithmetic Operators 
COLLATE Operator 

- Concatenation Operator 
Hierarchical Query Operators 

- Set Operators 
Multiset Operators 
User-Defined Operators 


This chapter discusses nonlogical (non-Boolean) operators. These operators cannot by themselves serve as the 
condition of a WHERE or HAVING clause in queries or subqueries. 


SQL Operators 


Operators manipulate individual data items called operands or arguments . Operators are represented by special 
characters or by keywords. For example, the multiplication operator is represented by an asterisk (*). 


If you have installed Oracle Text, then you can use the SCORE operator, which is part of that product, in Oracle 
Text queries. You can also create conditions with the built-in Text operators, 
including CONTAINS, CATSEARCH, and MATCHES. 


Unary and Binary Operators 
The two general classes of operators are: 


+ unary : A unary operator operates on only one operand. A unary operator typically appears with its 
operand in this format: 


operator operand 


- binary: A binary operator operates on two operands. A binary operator appears with its operands in this 
format: 


operand1 operator operand2 


Other operators with special formats accept more than two operands. If an operator is given a null operand, then 
the result is always null. The only operator that does not follow this rule is concatenation (||). 


Operator Precedence 


Precedence is the order in which Oracle Database evaluates different operators in the same expression. When 
evaluating an expression containing multiple operators, Oracle evaluates operators with higher precedence before 
evaluating those with lower precedence. Oracle evaluates operators with equal precedence from left to right within 
an expression. 


SQL Operator Precedence 
Operator Operation 


+, - (as unary Identity, negation, location in hierarchy 
operators), PRIOR, CONNECT_BY_ROOT, COLLATE 


¥ Multiplication, division 


+, - (as binary operators), || Addition, subtraction, concatenation 


Precedence Example 


In the following expression, multiplication has a higher precedence than addition, so Oracle first multiplies 2 by 3 
and then adds the result to 1. 


1+2*3 


You can use parentheses in an expression to override operator precedence. Oracle evaluates expressions inside 
parentheses before evaluating those outside. 


SQL also supports set operators (UNION, UNION ALL, INTERSECT, and MINUS), which combine sets of rows 
returned by queries, rather than individual data items. All set operators have equal precedence. 


Arithmetic Operators 


You can use an arithmetic operator with one or two arguments to negate, add, subtract, multiply, and divide 
numeric values. Some of these operators are also used in datetime and interval arithmetic. The arguments to the 
operator must resolve to numeric data types or to any data type that can be implicitly converted to a numeric data 


type. 


Unary arithmetic operators return the same data type as the numeric data type of the argument. For binary 
arithmetic operators, Oracle determines the argument with the highest numeric precedence, implicitly converts the 
remaining arguments to that data type, and returns that data type. 


Arithmetic Operators 


Operator Purpose Example 


Operator Purpose Example 


+- When these denote a positive or negative 
expression, they are unary operators. SELECT * 


FROM order_items 
WHERE quantity = -1 
ORDER BY order_id, 


line_item_id, product_id; 


SELECT * 


FROM employees 
WHERE -salary < 0 


ORDER BY employee_id; 


+- When they add or subtract, they are binary 
operators. SELECT hire_date 


FROM employees 
WHERE SYSDATE - hire_date > 365 


ORDER BY hire_date; 


me} Multiply, divide. These are binary operators. 
UPDATE employees 


SET salary = salary * 1.1; 


Do not use two consecutive minus signs (--) in arithmetic expressions to indicate double negation or the 
subtraction of a negative value. The characters -- are used to begin comments within SQL statements. You should 
separate consecutive minus signs with a space or parentheses. 


COLLATE Operator 


The COLLATE operator determines the collation for an expression. This operator enables you to override the 
collation that the database would have derived for the expression using standard collation derivation rules. 


COLLATE is a postfix unary operator. It has the same precedence as other unary operators, but it is evaluated after 
all prefix unary operators have been evaluated. 


You can apply this operator to expressions of type VARCHAR2, CHAR, LONG, NVARCHAR, or NCHAR. 


The COLLATE operator takes one argument, collation_name , for which you can specify a named collation or 
pseudo-collation. If the collation name contains a space, then you must enclose the name in double quotation 
marks. 


COLLATE Operator 


Operator Purpose Example 


COLLATE collation_name Determines the 


collation for an SELECT last_name 
expression 
FROM employees 


ORDER BY last_name COLLATE 
GENERIC_M; 


Concatenation Operator 


The concatenation operator manipulates character strings and CLOB data. 


Concatenation Operator 


Operator Purpose Example 


|| Concatenates character strings 
and CLOB data. SELECT ‘Name is ' || last_name 


FROM employees 


ORDER BY last_name; 


The result of concatenating two character strings is another character string. If both character strings are of data 
type CHAR, then the result has data type CHAR and is limited to 2000 characters. If either string is of data 

type VARCHAR2, then the result has data type VARCHAR2 and is limited to 32767 characters if the initialization 
parameter MAX_STRING_SIZE = EXTENDED and 4000 characters if MAX_STRING_SIZE = STANDARD. If 
either argument is a CLOB, the result is a temporary CLOB. Trailing blanks in character strings are preserved by 
concatenation, regardless of the data types of the string or CLOB. 


On most platforms, the concatenation operator is two solid vertical bars. However, some IBM platforms use 
broken vertical bars for this operator. When moving SQL script files between systems having different character 
sets, such as between ASCII and EBCDIC, vertical bars might not be translated into the vertical bar required by 
the target Oracle Database environment. Oracle provides the CONCAT character function as an alternative to the 
vertical bar operator for cases when it is difficult or impossible to control translation performed by operating 
system or network utilities. Use this function in applications that will be moved between environments with 
differing character sets. 


Although Oracle treats zero-length character strings as nulls, concatenating a zero-length character string with 
another operand always results in the other operand, so null can result only from the concatenation of two null 
strings. However, this may not continue to be true in future versions of Oracle Database. To concatenate an 

expression that might be null, use the NVL function to explicitly convert the expression to a zero-length string. 


Concatenation Example 


This example creates a table with both CHAR and VARCHAR2 columns, inserts values both with and without 
trailing blanks, and then selects these values and concatenates them. Note that for 
both CHAR and VARCHAR2 columns, the trailing blanks are preserved. 


CREATE TABLE tab1 (coll VARCHAR2(6), col2 CHAR(6), 
col3 VARCHAR2(6), col4 CHAR(6)); 


INSERT INTO tab1 (coll, col2, col3, col4) 
VALUES ('abc', 'def ','ghi ', 'jkl'); 


SELECT col! || col2 || col3 || col4 "Concatenation" 
FROM tab1; 


Concatenation 


abcdef ghi jkl 


Hierarchical Query Operators 
Two operators, PRIOR and CONNECT_BY_ROOT, are valid only in hierarchical queries. 
PRIOR 


In a hierarchical query, one expression in the CONNECT BY condition must be qualified by the PRIOR operator. 
If the CONNECT BY condition is compound, then only one condition requires the PRIOR operator, although you 
can have multiple PRIOR conditions. PRIOR evaluates the immediately following expression for the parent row of 
the current row in a hierarchical query. 


PRIOR is most commonly used when comparing column values with the equality operator. (The PRIOR keyword 
can be on either side of the operator.) PRIOR causes Oracle to use the value of the parent row in the column. 
Operators other than the equal sign (=) are theoretically possible in CONNECT BY clauses. However, the 
conditions created by these other operators can result in an infinite loop through the possible combinations. In this 
case Oracle detects the loop at run time and returns an error. 


CONNECT_BY_ROOT 


CONNECT_BY_ROOT is a unary operator that is valid only in hierarchical queries. When you qualify a column 
with this operator, Oracle returns the column value using data from the root row. This operator extends the 
functionality of the CONNECT BY [PRIOR] condition of hierarchical queries. 


Restriction on CONNECT BY ROOT 
You cannot specify this operator in the START WITH condition or the CONNECT BY condition. 


Set Operators 


Set operators combine the results of two component queries into a single result. Queries containing set operators 
are called compound queries. 


Set Operators 


Operator Returns 

UNION All distinct rows selected by either query 

UNION ALL All rows selected by either query, including all duplicates 
INTERSECT All distinct rows selected by both queries 

MINUS All distinct rows selected by the first query but not the second 


Multiset Operators 
Multiset operators combine the results of two nested tables into a single nested table. 


The examples related to multiset operators require that two nested tables be created and loaded with data as 
follows: 


First, make a copy of the oe.customers table called customers_demo: 


CREATE TABLE customers_demo AS 
SELECT * FROM customers; 


Next, create a table type called cust_address_tab_typ. This type will be used when creating the nested table 
columns. 


CREATE TYPE cust_address_tab_typ AS 
TABLE OF cust_address_typ; 
/ 


Now, create two nested table columns in the customers_demo table: 


ALTER TABLE customers_ demo 
ADD (cust_address_ntab cust_address_tab_typ, 
cust_address2_ntab cust_address_tab_typ) 
NESTED TABLE cust_address_ntab STORE AS cust_address_ntab_ store 
NESTED TABLE cust_address2_ntab STORE AS cust_address2_ntab_store; 


Finally, load data into the two new nested table columns using data from the cust_address column of 
the oe.customers table: 


UPDATE customers_demo cd 
SET cust_address_ntab = 
CAST(MULTISET(SELECT cust_address 
FROM customers c 
WHERE c.customer_id = 
cd.customer_id) as cust_address_tab_typ); 


UPDATE customers_demo cd 
SET cust_address2_ntab = 
CAST(MULTISET(SELECT cust_address 
FROM customers c 
WHERE c.customer_id = 
cd.customer_id) as cust_address_tab_typ); 


MULTISET EXCEPT 


MULTISET EXCEPT takes as arguments two nested tables and returns a nested table whose elements are in the 
first nested table but not in the second nested table. The two input nested tables must be of the same type, and the 
returned nested table is of the same type as well. 


Example 


The following example compares two nested tables and returns a nested table of those elements found in the first 
nested table but not in the second nested table: 


SELECT customer_id, cust_address_ntab 
MULTISET EXCEPT DISTINCT cust_address2_ntab multiset_except 
FROM customers_ demo 
ORDER BY customer_id; 


CUSTOMER_ID MULTISET_EXCEPT(STREET_ADDRESS, POSTAL_CODE, CITY, 
STATE_PROVINCE, COUNTRY_ID) 

101 CUST_ADDRESS_TAB_TYP() 

102 CUST_ADDRESS_TAB_TYP() 

103 CUST_ADDRESS_TAB_TYP() 

104 CUST_ADDRESS_TAB_TYP() 

105 CUST_ADDRESS_TAB_TYP() 


The preceding example requires the table customers_demo and two nested table columns containing data. 


MULTISET INTERSECT 


MULTISET INTERSECT takes as arguments two nested tables and returns a nested table whose values are 
common in the two input nested tables. The two input nested tables must be of the same type, and the returned 
nested table is of the same type as well. 


Example 


The following example compares two nested tables and returns a nested table of those elements found in both 
input nested tables: 


SELECT customer_id, cust_address_ntab 
MULTISET INTERSECT DISTINCT cust_address2_ntab multiset_intersect 
FROM customers_demo 
ORDER BY customer_id; 


CUSTOMER_ID MULTISET_INTERSECT(STREET_ADDRESS, POSTAL_CODE, CITY, 
STATE_PROVINCE, COUNTRY_ID 
101 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘514 W Superior St’, '46901', 'Kokomo', 
‘IN’, 'US')) 
102 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('2515 Bloyd Ave’, '46218', 'Indianapolis', 
‘IN’, 'US')) 
103 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('8768 N State Rd 37', '47404', 
‘Bloomington’, 'IN', 'US')) 
104 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('6445 Bay Harbor Ln’, '46254', 
‘Indianapolis’, 'IN', 'US')) 
105 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘4019 W 3Rd St’, '47404', ‘Bloomington’, 
‘IN’, 'US')) 


The preceding example requires the table customers_demo and two nested table columns containing data. 


MULTISET UNION 


MULTISET UNION takes as arguments two nested tables and returns a nested table whose values are those of the 
two input nested tables. The two input nested tables must be of the same type, and the returned nested table is of 
the same type as well. 


Example 


The following example compares two nested tables and returns a nested table of elements from both input nested 
tables: 


SELECT customer_id, cust_address_ntab 
MULTISET UNION cust_address2_ntab multiset_union 
FROM customers_demo 
ORDER BY customer_id; 


CUSTOMER_ID MULTISET_UNION(STREET_ADDRESS, POSTAL_CODE, CITY, 
STATE_PROVINCE, COUNTRY_ID) 

101 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘514 W Superior St’, '46901', 'Kokomo', 
‘IN’, US), 
CUST_ADDRESS_TYP(‘'514 W Superior St’, '46901', 'Kokomo'’, 'IN', 'US')) 

102 CUST_LADDRESS_TAB_TYP(CUST_ADDRESS_TYP('2515 Bloyd Ave’, '46218', Indianapolis’, 
‘IN’, US), 
CUST_ADDRESS_TYP('2515 Bloyd Ave’, '46218', Indianapolis’, 'IN',"US')) 

103 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('8768 N State Rd 37’, '47404', 
‘Bloomington’, 'IN', 'US'), 
CUST_ADDRESS_TYP('8768 N State Rd 37’, '47404', ‘Bloomington’, 'IN', 'US')) 

104 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('6445 Bay Harbor Ln’, '46254', 
‘Indianapolis’, 'IN', 'US'), 
CUST_ADDRESS_TYP('6445 Bay Harbor Ln’, '46254', Indianapolis’, 'IN', 'US')) 

105 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘4019 W 3Rd St’, '47404', ‘Bloomington’, 
‘IN’, 'US'), 


CUST_ADDRESS_TYP('4019 W 3Rd St’, '47404', 'Bloomington’, 'IN', 'US')) 


The preceding example requires the table customers_demo and two nested table columns containing data. 


User-Defined Operators 


Like built-in operators, user-defined operators take a set of operands as input and return a result. However, you 
create them with the CREATE OPERATOR statement, and they are identified by user-defined names. They reside 
in the same namespace as tables, views, types, and standalone functions. 


After you have defined a new operator, you can use it in SQL statements like any other built-in operator. For 
example, you can use user-defined operators in the select list of a SELECT statement, the condition of 

a WHERE clause, or in ORDER BY clauses and GROUP BY clauses. However, you must 

have EXECUTE privilege on the operator to do so, because it is a user-defined object. 


Expressions 
This section describes how to combine values, operators, and functions into expressions . 
This segment includes these sections: 


SQL Expressions 
Simple Expressions 

- Analytic View Expressions 
Compound Expressions 
CASE Expressions 

- Column Expressions 
CURSOR Expressions 

- Datetime Expressions 


Function Expressions 


Interval Expressions 
JSON Object Access Expressions 
e Model Expressions 
Object Access Expressions 
- Placeholder Expressions 
Scalar Subquery Expressions 
Type Constructor Expressions 
- Expression Lists 


SQL Expressions 


An expression is a combination of one or more values, operators, and SQL functions that evaluates to a value. 
An expression generally assumes the data type of its components. 


This simple expression evaluates to 4 and has data type NUMBER (the same data type as its components): 


2*2 


The following expression is an example of a more complex expression that uses both functions and operators. The 
expression adds seven days to the current date, removes the time component from the sum, and converts the result 
to CHAR data type: 


TO_CHAR(TRUNC(SYSDATE+7)) 


You can use expressions in: 


- The select list of the SELECT statement 
A condition of the WHERE clause and HAVING clause 

- The CONNECT BY, START WITH, and ORDER BY clauses 
The VALUES clause of the INSERT statement 
The SET clause of the UPDATE statement 


For example, you could use an expression in place of the quoted string 'Smith' in 
this UPDATE statement SET clause: 
SET last_name = ‘Smith’; 
This SET clause has the expression INITCAP(last_name) instead of the quoted string 'Smith': 


SET last_name = INITCAP(last_name); 


Simple Expressions 


A simple expression specifies a column, pseudocolumn, constant, sequence number, or null. 


In addition to the schema of a user, schema can also be "PUBLIC" (double quotation marks required), in which 
case it must qualify a public synonym for a table, view, or materialized view. Qualifying a public synonym with 


"PUBLIC" is supported only in data manipulation language (DML) statements, not data definition language (DDL) 
statements. 


You can specify ROWID only with a table, not with a view or materialized view. NCHAR and NVARCHAR2 are 
not valid pseudocolumn data types. 


Some valid simple expressions are: 


employees.last_name 

this is a text string’ 

10 

N'this is an NCHAR string' 


Analytic View Expressions 


You can use analytic view expressions to create calculated measures within the definition of an analytic view or in 
a query that selects from an analytic view. 


Analytic view expressions differ from other types of expressions in that they reference elements of hierarchies and 
analytic views rather than tables and columns. 


An analytic view expression is one of the following: 


- An av_meas_expression , which is based on a measure in an analytic view 


An av_hier_expression , which returns an attribute value of the related member 


You use an analytic view expression as the calc_meas_expression parameter in a calc_measure_clause in 
a CREATE ANALYTIC VIEW statement and in the WITH or FROM clauses of a SELECT statement. 


In defining a calculated measure, you may also use the following types of expression: 
- Simple 
Case 
- Compound 
Datetime 
Interval 


Examples of Analytic View Expressions 


This topic contains examples that show calculated measures defined in the MEASURES clause of an analytic view 
and in the ADD MEASURES clause of a SELECT statement. 


Examples of LAG Expressions 
These calculated measures different LAG operations. 


-- These calculated measures are from the measures_clause of the 
-- sales_av analytic view. 


MEASURES 

(sales FACT sales, -- A base measure 
units FACT units, -- A base measure 
sales_prior_period AS -- Calculated measures 


(LAG(sales) OVER (HIERARCHY time_hier OFFSET 1)), 
sales_year_ago AS 

(LAG(sales) OVER (HIERARCHY time_hier OFFSET 1 

ACROSS ANCESTOR AT LEVEL year)), 
chg_sales_year_ago AS 

(LAG_DIFF(sales) OVER (HIERARCHY time_hier OFFSET 1 


ACROSS ANCESTOR AT LEVEL year)), 
pct_chg_sales_year_ago AS 
(LAG_DIFF_PERCENT(sales) OVER (HIERARCHY time_hier OFFSET 1 
ACROSS ANCESTOR AT LEVEL year)), 
sales_qtr_ago AS 
(LAG(sales) OVER (HIERARCHY time_hier OFFSET 1 
ACROSS ANCESTOR AT LEVEL quarter)), 
chg_sales_qtr_ago AS 
(LAG_DIFF(sales) OVER (HIERARCHY time_hier OFFSET 1 
ACROSS ANCESTOR AT LEVEL quarter)), 
pct_chg_sales_qtr_ago AS 
(LAG_DIFF_PERCENT(sales) OVER (HIERARCHY time_hier OFFSET 1 
ACROSS ANCESTOR AT LEVEL quarter)) 


) 


Example of a Window Expression 


This calculated measure uses a window operation. 


MEASURES 
(sales FACT sales, 
units FACT units, 
sales_qtd AS 
(SUM(sales) OVER (HIERARCHY time_hier 
BETWEEN UNBOUNDED PRECEDING AND CURRENT MEMBER 
WITHIN ANCESTOR AT LEVEL QUARTER)), 
sales_ytd AS 
(SUM(sales) OVER (HIERARCHY time_hier 
BETWEEN UNBOUNDED PRECEDING AND CURRENT MEMBER 
WITHIN ANCESTOR AT LEVEL YEAR)) 
) 


Examples of SHARE OF Expressions 


These calculated measures use SHARE OF expressions. 


MEASURES 
(sales FACT sales, 

units FACT units, 
sales_shr_parent_prod AS 

(SHARE_OF(sales HIERARCHY product_hier PARENT)), 
sales_shr_parent_geog AS 

(SHARE_OF(sales HIERARCHY geography_hier PARENT)), 
sales_shr_region AS 

(SHARE_OF(sales HIERARCHY geography_hier LEVEL REGION)) 
) 


Examples of QDR Expressions 


These calculated measures use the QUALIFY keyword to specify qualified data reference expressions. 


MEASURES 
(sales FACT sales, 
units FACT units, 
sales_2011 AS 
(QUALIFY (sales, time_hier = year['11'])), 


sales_pct_chg_ 2011 AS 
((sales - (QUALIFY (sales, time_hier = year['11']))) / 
(QUALIFY (sales, time_hier = year['11']))) 
) 


Example of an Added Measure Using the RANK Function 


In this example, the units_geog_rank_level measure uses the RANK function to rank geography hierarchy 
members within a level based on units. 


SELECT geography_hier.member_name AS "Region", 
units AS "Units", 
units_geog_rank_level AS "Rank" 
FROM ANALYTIC VIEW ( 
USING sales_av HIERARCHIES (geography_hier) 
ADD MEASURES ( 
units_geog_rank_level AS ( 
RANKQO OVER ( 
HIERARCHY geography_hier 
ORDER BY units desc nulls last 
WITHIN LEVEL)) 
) 


) 
WHERE geography_hier.level_name IN (‘REGION’) 
ORDER BY units_geog_rank_level; 


The following is the result of the query. 


Regions Units Rank 
Asia 56017849 1 
South America 23904155 2 
North America 20523698 3 
Africa 12608308 4 
Europe 8666520 5 
Oceania 427664 6 


Compound Expressions 


A compound expression specifies a combination of other expressions. 


Some valid compound expressions are: 


(‘CLARK' || 'SMITH') 

LENGTH('MOOSFE') * 57 

SQRT(144) + 72 
my_fun(TO_CHAR(sysdate,,DD-MMM-YY')) 
name COLLATE BINARY_ CI 


CASE Expressions 


CASE expressions let you use IF ... THEN ... ELSE logic in SQL statements without having to invoke procedures. 


Simple CASE Example 


For each customer in the sample oe.customers table, the following statement lists the credit limit as "Low" if it 
equals $100, "High" if it equals $5000, and "Medium" if it equals anything else. 


SELECT cust_last_name, 
CASE credit_limit WHEN 100 THEN ‘Low' 
WHEN 5000 THEN 'High' 
ELSE 'Medium' END AS credit 
FROM customers 
ORDER BY cust_last_name, credit; 


CUST_LAST_NAME CREDIT 


Adjani Medium 
Adjani Medium 
Alexander Medium 
Alexander Medium 
Altman High 
Altman Medium 
Searched CASE Example 


The following statement finds the average salary of the employees in the sample table oe.employees, using $2000 
as the lowest salary possible: 


SELECT AVG(CASE WHEN e.salary > 2000 THEN e.salary 
ELSE 2000 END) "Average Salary" FROM employees e; 


Average Salary 


6461.68224 


Column Expressions 


A column expression, which is designated as column_expression in subsequent syntax diagrams, is a limited form 
of expr. A column expression can be a simple expression, compound expression, function expression, or 
expression list, but it can contain only the following forms of expression: 


Columns of the subject table — the table being created, altered, or indexed 
Constants (strings or numbers) 


- Deterministic functions — either SQL built-in functions or user-defined functions 


No other expression forms described in this chapter are valid. In addition, compound expressions using 
the PRIOR keyword are not supported, nor are aggregate functions. 


You can use a column expression for these purposes: 


To create a function-based index. 


- To explicitly or implicitly define a virtual column. When you define a virtual column, the defining 
column_expression must refer only to columns of the subject table that have already been defined, in the 
current statement or in a prior statement. 


The combined components of a column expression must be deterministic. That is, the same set of input values 
must return the same set of output values. 


CURSOR Expressions 


A CURSOR expression returns a nested cursor. This form of expression is equivalent to the 
PL/SQL REF CURSOR and can be passed as a REF CURSOR argument to a function. 


A nested cursor is implicitly opened when the cursor expression is evaluated. For example, if the cursor expression 
appears in a select list, a nested cursor will be opened for each row fetched by the query. The nested cursor is 
closed only when: 


The nested cursor is explicitly closed by the user 
The parent cursor is reexecuted 

The parent cursor is closed 

The parent cursor is cancelled 


- An error arises during fetch on one of its parent cursors (it is closed as part of the clean-up) 
Restrictions on CURSOR Expressions 
The following restrictions apply to CURSOR expressions: 


- Ifthe enclosing statement is not a SELECT statement, then nested cursors can appear only 
as REF CURSOR arguments of a procedure. 


If the enclosing statement is a SELECT statement, then nested cursors can also appear in the outermost 
select list of the query specification or in the outermost select list of another nested cursor. 


- Nested cursors cannot appear in views. 
You cannot perform BIND and EXECUTE operations on nested cursors. 
Examples 


The following example shows the use of a CURSOR expression in the select list of a query: 


SELECT department_name, CURSOR(SELECT salary, commission_pct 
FROM employees e 
WHERE e.department_id = d.department_id) 
FROM departments d 
ORDER BY department_name; 


The next example shows the use of a CURSOR expression as a function argument. The example begins by 
creating a function in the sample OE schema that can accept the REF CURSOR argument. (The PL/SQL function 
body is shown in italics.) 


CREATE FUNCTION f(cur SYS_REFCURSOR, mgr_hiredate DATE) 
RETURN NUMBER IS 
emp_hiredate DATE; 
before number :=0; 
after number: =0; 

begin 
loop 

fetch cur into emp_hiredate; 

exit when cur%NOTFOUND; 

if emp_hiredate > mgr_hiredate then 
after: =after+1; 

else 
before: =before+ 1; 

end if; 

end loop; 


close cur; 
if before > after then 
return 1; 
else 
return 0; 
end if; 
end ; 
/ 


The function accepts a cursor and a date. The function expects the cursor to be a query returning a set of dates. The 
following query uses the function to find those managers in the sample employees table, most of whose employees 
were hired before the manager. 


SELECT e1.last_name FROM employees e1 
WHERE f( 
CURSOR(SELECT e2.hire_date FROM employees e2 
WHERE el.employee_id = e2.manager_id), 
e1.hire_date) = 1 
ORDER BY last_name; 


LAST_NAME 
Cambrault 
Higgins 
Hunold 
Kochhar 
Mourgos 
Zlotkey 


Datetime Expressions 


A datetime expression yields a value of one of the datetime data types. 


The initial expr is any expression, except a scalar subquery expression, that evaluates to a value of data 

type TIMESTAMP, TIMESTAMP WITH TIME ZONE, or TIMESTAMP WITH LOCAL TIME ZONE. 

The DATE data type is not supported. If this expr is itself a datetime_expression , then it must be enclosed in 
parentheses. 


Datetimes and intervals can be combined. The three combinations that yield datetime values are valid in a datetime 
expression. 


If you specify AT LOCAL, then Oracle uses the current session time zone. 

The settings for AT TIME ZONE are interpreted as follows: 
The string '[+|-] hh: mi ' specifies a time zone as an offset from UTC. For hh, specify the number of 
hours. For mi, specify the number of minutes. 


DBTIMEZONE: Oracle uses the database time zone established (explicitly or by default) during database 
creation. 


SESSIONTIMEZONE: Oracle uses the session time zone established by default or in the most 
recent ALTER SESSION statement. 


time_zone_name: Oracle returns the datetime_value_expr in the time zone indicated by time_zone_name 
. For a listing of valid time zone region names, query the VSTIMEZONE_NAMES dynamic performance 
view. 


Example 


The following example converts the datetime value of one time zone to another time zone: 


SELECT FROM_TZ(CAST(TO_DATE(‘1999-12-01 11:00:00', 
"YY Y Y-MM-DD HH:MI:SS') AS TIMESTAMP), 'America/New_York') 
AT TIME ZONE 'America/Los_Angeles' "West Coast Time" 
FROM DUAL; 


West Coast Time 


01-DEC-99 08.00.00.000000 AM AMERICA/LOS_ANGELES 


Function Expressions 


You can use any built-in SQL function or user-defined function as an expression. Some valid built-in function 
expressions are: 


LENGTH('BLAKE)) 
ROUND(1234.567*43) 
SYSDATE 


Some valid user-defined function expressions are: 


circle_area(radius) 

payroll.tax_rate(empno) 
hr.employees.comm_pct@remote(dependents, empno) 
DBMS_LOB.getlength(column_name) 
my_function(a_column) 


In a user-defined function being used as an expression, positional, named, and mixed notation are supported. For 
example, all of the following notations are correct: 


CALL my_function(arg1 => 3, arg2 => 4)... 
CALL my_function(3, 4) ... 


CALL my_function(3, arg2 => 4) ... 


Restriction on User-Defined Function Expressions 
You cannot pass arguments of object type or XMLType to remote functions and procedures. 


Interval Expressions 


An interval expression yields a value of INTERVAL YEAR TO MONTH or INTERVAL DAY TO SECOND. 


The expressions expr1 and expr2 can be any expressions that evaluate to values of data 
type DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, or TIMESTAMP WITH LOCAL TIME ZONE. 


Both leading_field_precision and fractional_second_precision can be any integer from 0 to 9. If you omit the 
leading_field_precision for either DAY or YEAR, then Oracle Database uses the default value of 2. If you omit 
the fractional_second_precision for second, then the database uses the default value of 6. If the value returned by 
a query contains more digits that the default precision, then Oracle Database returns an error. Therefore, it is good 
practice to specify a precision that you know will be at least as large as any value returned by the query. 


For example, the following statement subtracts the value of the order_date column in the sample table orders (a 
datetime value) from the system timestamp (another datetime value) to yield an interval value expression. It is not 
known how many days ago the oldest order was placed, so the maximum value of 9 for the DAY leading field 
precision is specified: 


SELECT (SYSTIMESTAMP - order_date) DAY(9) TO SECOND FROM orders 
WHERE order_id = 2458; 


JSON Object Access Expressions 


A JSON object access expression is used only when querying a column of JavaScript Object Notation (JSON) 
data. It yields a character string that contains one or more JSON values found in that data. The syntax for this type 
of expression is called dot-notation syntax. 


A JSON object access expression yields a character string of data type VARCHAR2(4000), which contains the 
targeted JSON value(s) as follows: 


- Fora single targeted value, the character string contains that value, whether it is a JSON scalar value, 
object, or array. 
For multiple targeted values, the character string contains a JSON array whose elements are those values. 


If you omit JSON_object_key , then the expression yields a character string that contains the JSON data in its 
entirety. In this case, the character string is of the same data type as the column of JSON data being queried. 


A JSON object access expression cannot return a value larger than 4K bytes. If the value surpasses this limit, then 
the expression returns null. To obtain the actual value, instead use the JSON_QUERY function or 
the JSON_VALUE function and specify an appropriate return type with the RETURNING clause. 


The collation derivation rules for the JSON object access expression are the same as for 
the JSON_QUERY function. 


Examples 


The following examples use the j_purchaseorder table. This table contains a column of JSON data 
called po_document. These examples return JSON values from column po_document. 


The following statement returns the value of the property with key name PONumber: 


SELECT po.po_document.PONumber 
FROM j_purchaseorder po; 


PONumber 


The following statement first targets the property with key name ShippingInstructions, whose value is a JSON 
object. The statement then targets the property with key name Phone within that object. The statement returns the 
value of Phone, which is a JSON array. 


SELECT po.po_document.ShippingInstructions.Phone 
FROM j_purchaseorder po; 


SHIPPINGINSTRUCTIONS 


[{"type":"Office","number":"909-555-7307"}, {"type":"Mobile","number":"415-555-1234"}] 


The following statement first targets the property with key name Lineltems, whose value is a JSON array. The 
expression implicitly unwraps the array and evaluates its elements, which are JSON objects. Next, the statement 
targets the properties with key name Part, within the unwrapped objects, and finds two objects. The statement then 
targets the properties with key name Description within those two objects and finds string values. Because more 
than one value is returned, the values are returned as elements of a JSON array. 


SELECT po.po_document.Lineltems.Part.Description 
FROM j_purchaseorder po; 


LINEITEMS 


[One Magic Christmas,Lethal Weapon] 


Model Expressions 


A model expression is used only in the model_clause of a SELECT statement and then only on the right-hand 
side of a model rule. It yields a value for a cell in a measure column previously defined in the model_clause . 


When you specify a measure column in a model expression, any conditions and expressions you specify must 
resolve to single values. 


When you specify an aggregate function in a model expression, the argument to the function is a measure column 
that has been previously defined in the model_clause . An aggregate function can be used only on the right-hand 
side of a model rule. 


Specifying an analytic function on the right-hand side of the model rule lets you express complex calculations 
directly in the model_clause . The following restrictions apply when using an analytic function in a model 
expression: 


Analytic functions can be used only in an UPDATE rule. 


You cannot specify an analytic function on the right-hand side of the model rule if the left-hand side of the 
rule contains a FOR loop or an ORDER BY clause. 


The arguments in the OVER clause of the analytic function cannot contain an aggregate. 


The arguments before the OVER clause of the analytic function cannot contain a cell reference. 


When expr is itself a model expression, it is referred to asa nested cell reference . The following restrictions 
apply to nested cell references: 


Only one level of nesting is allowed. 
A nested cell reference must be a single-cell reference. 


e When AUTOMATIC ORDER is specified in the model_rules_clause , a nested cell reference can be used 
on the left-hand side of a model rule only if the measures used in the nested cell reference remain static. 


The model expressions shown below are based on the model_clause of the following SELECT statement: 


SELECT country,prod,year,s 

FROM sales_view_ref 

MODEL 
PARTITION BY (country) 
DIMENSION BY (prod, year) 
MEASURES (sale s) 
IGNORE NAV 
UNIQUE DIMENSION 
RULES UPSERT SEQUENTIAL ORDER 


( 


s[prod="Mouse Pad', year=2000] = 
s['Mouse Pad', 1998] + s['Mouse Pad', 1999], 
s['Standard Mouse’, 2001] = s['Standard Mouse’, 2000] 


) 
ORDER BY country, prod, year; 


The following model expression represents a single cell reference using symbolic notation. It represents the sales 
of the Mouse Pad for the year 2000. 


s[prod='"Mouse Pad',year=2000] 


The following model expression represents a multiple cell reference using positional notation, using 
the CV function. It represents the sales of the current value of the dimension column prod for the year 2001. 


s[CV(prod), 2001] 


The following model expression represents an aggregate function. It represents the sum of sales of the Mouse Pad 
for the years between the current value of the dimension column year less two and the current value of the 
dimension column year less one. 


SUM(s)['Mouse Pad', year BETWEEN CV()-2 AND CV()-1] 


Object Access Expressions 


An object access expression specifies attribute reference and method invocation. 


The column parameter can be an object or REF column. If you specify expr , then it must resolve to an object 
type. 


When a type's member function is invoked in the context of a SQL statement, if the SELF argument is null, Oracle 
returns null and the function is not invoked. 


Examples 


The following example creates a table based on the sample oe.order_item_typ object type, and then shows how 
you would update and select from the object column attributes. 


CREATE TABLE short_orders ( 
sales_rep VARCHAR2(25), item order_item_typ); 


UPDATE short_orders s SET sales_rep = 'Unassigned'; 
SELECT o0.item.line_item_id, 0.item.quantity FROM short_orders 0; 


Placeholder Expressions 


A placeholder expression provides a location in a SQL statement for which a third-generation language bind 
variable will provide a value. You can specify the placeholder expression with an optional indicator variable. This 
form of expression can appear only in embedded SQL statements or SQL statements processed in an Oracle Call 
Interface (OCI) program. 


Some valid placeholder expressions are: 


:employee_name INDICATOR :employee_name_indicator_var 
:department_location 


Scalar Subquery Expressions 


A scalar subquery expression is a subquery that returns exactly one column value from one row. The value of the 
scalar subquery expression is the value of the select list item of the subquery. If the subquery returns 0 rows, then 
the value of the scalar subquery expression is NULL. If the subquery returns more than one row, then Oracle 
returns an error. 


You can use a scalar subquery expression in most syntax that calls for an expression ( expr ). In all cases, a scalar 
subquery must be enclosed in its own parentheses, even if its syntactic location already positions it within 
parentheses (for example, when the scalar subquery is used as the argument to a built-in function). 


Scalar subqueries are not valid expressions in the following places: 


- As default values for columns 

- As hash expressions for clusters 

- Inthe RETURNING clause of DML statements 

- As the basis of a function-based index 

- In CHECK constraints 

- In GROUP BY clauses 

- In statements that are unrelated to queries, such as CREATE PROFILE 


Type Constructor Expressions 


A type constructor expression specifies a call to a constructor method. The argument to the type constructor is any 
expression. Type constructors can be invoked anywhere functions are invoked. 


The NEW keyword applies to constructors for object types but not for collection types. It instructs Oracle to 
construct a new object by invoking an appropriate constructor. The use of the NEW keyword is optional, but it is 
good practice to specify it. 


If type_name isan object type , then the expressions must be an ordered list, where the first argument is a value 
whose type matches the first attribute of the object type, the second argument is a value whose type matches the 
second attribute of the object type, and so on. The total number of arguments to the constructor must match the 
total number of attributes of the object type. 


If type_name isa varray or nested table type , then the expression list can contain zero or more arguments. 
Zero arguments implies construction of an empty collection. Otherwise, each argument corresponds to an element 
value whose type is the element type of the collection type. 


Restriction on Type Constructor Invocation 


In an invocation of a type constructor method, the number of parameters ( expr ) specified cannot exceed 999, even 
if the object type has more than 999 attributes. This limitation applies only when the constructor is called from 
SQL. For calls from PL/SQL, the PL/SQL limitations apply. 


Expression Example 


This example uses the cust_address_typ type in the sample oe schema to show the use of an expression in the call 
to a constructor method (the PL/SQL is shown in italics): 


CREATE TYPE address_book_t AS TABLE OF cust_address_typ; 
DECLARE 
myaddr cust_address_typ := cust_address_typ( 


'500 Oracle Parkway’, 94065, 'Redwood Shores’, 'CA','USA'); 
alladdr address_book_t := address_book_t(); 
BEGIN 
INSERT INTO customers VALUES ( 
666999, 'Joe', 'Smith', myaddr, NULL, NULL, NULL, NULL, 
NULL, NULL, NULL, NULL, NULL, NULL, NULL); 
END; 
/ 


Subquery Example 


This example uses the warehouse_typ type in the sample schema oe to illustrate the use of a subquery in the call to 
the constructor method. 


CREATE TABLE warehouse_tab OF warehouse_typ; 


INSERT INTO warehouse_tab 
VALUES (warehouse_typ(101, 'new_wh', 201)); 


CREATE TYPE facility_typ AS OBJECT ( 
facility_id NUMBER, 
warehouse_ref REF warehouse_typ); 


CREATE TABLE buildings (b_id NUMBER, building facility_typ); 


INSERT INTO buildings VALUES (10, facility_typ(102, 
(SELECT REF(w) FROM warehouse_tab w 
WHERE warehouse_name = 'new_wh'))); 


SELECT b.b_id, b.building.facility_id "FAC_ID", 
DEREF(b.building.warehouse_ref) "WH" FROM buildings b; 


B_ID FAC_ID WH(WAREHOUSE_ID, WAREHOUSE NAME, LOCATION_ID) 


10 102 WAREHOUSE_TYP(101, 'new_wh’, 201) 


Expression Lists 


An expression list is a combination of other expressions. 


Expression lists can appear in comparison and membership conditions and in GROUP BY clauses of queries and 
subqueries. An expression lists in a comparision or membership condition is sometimes referred to as a row value 
constructor or row constructor . 


Comparison and membership conditions appear in the conditions of WHERE clauses. They can contain either one 
or more comma-delimited expressions or one or more sets of expressions where each set contains one or more 
comma-delimited expressions. In the latter case (multiple sets of expressions): 
Each set is bounded by parentheses 
Each set must contain the same number of expressions 
- The number of expressions in each set must match the number of expressions before the operator in the 
comparison condition or before the IN keyword in the membership condition. 


A comma-delimited list of expressions can contain no more than 1000 expressions. A comma-delimited list of sets 
of expressions can contain any number of sets, but each set can contain no more than 1000 expressions. 


The following are some valid expression lists in conditions: 


(10, 20, 40) 
(‘SCOTT', 'BLAKE', 'TAYLOR’) 
( ‘Guy’, 'Himuro', 'GHIMURO’),(‘Karen', 'Colmenares', 'KCOLMENA') ) 


In the third example, the number of expressions in each set must equal the number of expressions in the first part 
of the condition. For example: 


SELECT * FROM employees 
WHERE ( first_name, last_name, email ) IN 
((‘Guy', 'Himuro', 'GHIMURO’'),('"Karen', 'Colmenares', 'KCOLMENA')) 


In a simple GROUP BY clause, you can use either the upper or lower form of expression list: 


SELECT department_id, MIN(salary) min, MAX(salary) max FROM employees 
GROUP BY department_id, salary 
ORDER BY department_id, min, max; 


SELECT department_id, MIN(salary) min, MAX(salary) max FROM employees 
GROUP BY (department_id, salary) 
ORDER BY department_id, min, max; 


In ROLLUP, CUBE, and GROUPING SETS clauses of GROUP BY clauses, you can combine individual 
expressions with sets of expressions in the same expression list. The following example shows several valid 
grouping sets expression lists in one SQL statement: 


SELECT 
prod_category, prod_subcategory, country_id, cust_city, count(*) 
FROM products, sales, customers 
WHERE sales.prod_id = products.prod_id 
AND sales.cust_id=customers.cust_id 
AND sales.time_id = '01-oct-00' 
AND customers.cust_year_of_birth BETWEEN 1960 and 1970 
GROUP BY GROUPING SETS 
( 
( prod_category, prod_subcategory, country_id, cust_city ), 
( prod_category, prod_subcategory, country_id ), 
( prod_category, prod_subcategory ), 
country_id 


) 
ORDER BY prod_category, prod_subcategory, country_id, cust_city; 


Conditions 


A condition specifies a combination of one or more expressions and logical (Boolean) operators and returns a 
value of TRUE, FALSE, or UNKNOWN. 


This chapter contains the following sections: 


SQL Conditions 


- Comparison Conditions 


Floating-Point Conditions 
Logical Conditions 

e Model Conditions 
Multiset Conditions 
Pattern-matching Conditions 

- Null Conditions 
XML Conditions 

+ SQL/JSON Conditions 
Compound Conditions 
BETWEEN Condition 

- EXISTS Condition 
IN Condition 
IS OF type Condition 

SQL Conditions 


Conditions can have several forms, as shown in the following syntax. 


If you have installed Oracle Text, then you can create conditions with the built-in operators that are part of that 
product, including CONTAINS, CATSEARCH, and MATCHES. 


The sections that follow describe the various forms of conditions. You must use appropriate condition syntax 
whenever condition appears in SQL statements. 


You can use a condition in the WHERE clause of these statements: 


DELETE 
SELECT 
- UPDATE 


You can use a condition in any of these clauses of the SELECT statement: 


WHERE 
«+ START WITH 
CONNECT BY 
- HAVING 


A condition could be said to be of a logical data type, although Oracle Database does not formally support such a 
data type. 


The following simple condition always evaluates to TRUE: 


The following more complex condition adds the salary value to the commission_pct value (substituting the value 0 
for null) and determines whether the sum is greater than the number constant 25000: 


NVL(salary, 0) + NVL(salary + (salary*commission_pct, 0) > 25000) 


Logical conditions can combine multiple conditions into a single condition. For example, you can use 
the AND condition to combine two conditions: 


(1=1) AND (5<7) 


Here are some valid conditions: 


name = 'SMITH' 

employees.department_id = departments.department_id 
hire_date > '01-JAN-08' 

job_id IN (SA_MAN', 'SA_REP') 

salary BETWEEN 5000 AND 10000 

commission_pct IS NULL AND salary = 2100 


Oracle Database does not accept all conditions in all parts of all SQL statements. Refer to the section devoted to a 
particular SQL statement in this book for information on restrictions on the conditions in that statement. 


Condition Precedence 


Precedence is the order in which Oracle Database evaluates different conditions in the same expression. When 
evaluating an expression containing multiple conditions, Oracle evaluates conditions with higher precedence 
before evaluating those with lower precedence. Oracle evaluates conditions with equal precedence from left to 
right within an expression, with the following exceptions: 


Left to right evaluation is not guaranteed for multiple conditions connected using AND 


Left to right evaluation is not guaranteed for multiple conditions connected using OR 


SQL Condition Precedence 


Type of Condition Purpose 


l=, <, >, <=, >=, comparison 


’ 


IS [NOT] NULL, LIKE, [NOT] BETWEEN, [NOT] IN, comparison 
EXISTS, IS OF type 


NOT exponentiation, logical negation 
AND conjunction 
OR disjunction 


Comparison Conditions 


Comparison conditions compare one expression with another. The result of such a comparison can 
be TRUE, FALSE, or UNKNOWN. 


Large objects (LOBs) are not supported in comparison conditions. However, you can use PL/SQL programs for 
comparisons on CLOB data. 


When comparing numeric expressions, Oracle uses numeric precedence to determine whether the condition 
compares NUMBER, BINARY_FLOAT, or BINARY_DOUBLE values. 


The rules define how the character sets of the expressions are aligned before the comparison, the use of binary or 
linguistic comparison (collation), the use of blank-padded comparison semantics, and the restrictions resulting 
from limits imposed on collation keys, including reporting of the error ORA- 

12742: unable to create the collation key. 


Two objects of nonscalar type are comparable if they are of the same named type and there is a one-to-one 
correspondence between their elements. In addition, nested tables of user-defined object types, even if their 
elements are comparable, must have MAP methods defined on them to be used in equality or IN conditions. 


Comparison Conditions 


Type of 
Condition Purpose Example 
= Equality test. 
SELECT * 
FROM employees 
WHERE salary = 2500 
ORDER BY employee_id; 
I= Inequality test. 
A= SELECT * 
<> 
FROM employees 
WHERE salary != 2500 
ORDER BY employee_id; 
> Greater-than and less-than tests. 
< SELECT * FROM employees 
WHERE salary > 2500 
ORDER BY employee_id; 
SELECT * FROM employees 
WHERE salary < 2500 
ORDER BY employee_id; 
>= Greater-than-or-equal-to and less-than-or-equal-to 
<= tests. SELECT * FROM employees 


WHERE salary >= 2500 
ORDER BY employee_id; 
SELECT * FROM employees 

WHERE salary <= 2500 


ORDER BY employee_id; 


Type of 


Condition Purpose Example 
op ANY "op" must be one of =, !=, >, <, <=, or >=. 
op SOME op ANY compares a value on the left side either to SELECT * FROM employees 


each value in a list, or to each value returned by a 
query, whichever is specified on the right side, using 
the condition op. 


WHERE salary = ANY 


If any of these comparisons returns TRUE, op 


ANY returns TRUE. (SELECT salary 
If all of these comparisons return FALSE, or the 
subquery on the right side returns no rows, op FROM employees 
ANY returns FALSE. Otherwise, the return value wy 
is UNKNOWN. WHERE department_id = 30) 
op ANY and op SOME are synonymous. ORDER BY employee_id; 
op ALL "op" must be one of =, !=, >, <, <=, or >=. 
op ALL compares a value on the left side either to SELECT * FROM employees 


each value in a list, or to each value returned by a 
subquery, whichever is specified on the right side, 


using the condition op. ALL (1400, 3000) 


If any of these comparisons returns FALSE, op 
ANY returns FALSE. 


If all of these comparisons return TRUE, or the 
subquery on the right side returns no rows, op 
ALL returns TRUE . Otherwise, the return value 
is UNKNOWN. 


WHERE salary >= 


ORDER BY employee_id; 


Simple Comparison Conditions 
A simple comparison condition specifies a comparison with expressions or subquery results. 


If you use the lower form of this condition with a single expression to the left of the operator, then you can use the 
upper or lower form of expression_list . If you use the lower form of this condition with multiple expressions to 
the left of the operator, then you must use the lower form of expression_list . In either case, the expressions in 
expression_list must match in number and data type the expressions to the left of the operator. If you specify 
subquery , then the values returned by the subquery must match in number and data type the expressions to the left 
of the operator. 


Group Comparison Conditions 
A group comparison condition specifies a comparison with any or all members in a list or subquery. 


If you use the upper form of this condition (with a single expression to the left of the operator), then you must use 
the upper form of expression_list . If you use the lower form of this condition (with multiple expressions to the 
left of the operator), then you must use the lower form of expression_list , and the expressions in each 
expression_list must match in number and data type the expressions to the left of the operator. If you specify 
subquery , then the values returned by the subquery must match in number and data type the expressions to the left 
of the operator. 


Floating-Point Conditions 


The floating-point conditions let you determine whether an expression is infinite or is the undefined result of an 
operation (is not a number or NaN). 


In both forms of floating-point condition, expr must resolve to a numeric data type or to any data type that can be 
implicitly converted to a numeric data type. 


Floating-Point Conditions 


Type of 
Condition Operation Example 
Returns TRUE if expr is the special 
IS [NOT] value NaN when NOT is not specified. SELECT COUNT(*) FROM employees 
NAN Returns TRUE if expr is not the special 
value NaN when NOT is specified. WHERE commission_pct Is NOT NAN; 
Returns TRUE if expr is the special 
IS [NOT] value +INF or -INF when NOT is not SELECT last_name FROM employees 
INFINITE specified. Returns TRUE if expr is 
neither +INF nor -INF when NOT is WHERE salary IS NOT INFINITE; 
specified. 


Logical Conditions 


A logical condition combines the results of two component conditions to produce a single result based on them or 
to invert the result of a single condition. 


Logical Conditions 


Type of 
Condition Operation Examples 
Returns TRUE if the following 
NOT condition is FALSE. Returns FALSE if SELECT * 
it is TRUE. If it is UNKNOWN, then it 
remains UNKNOWN. FROM employees 


WHERE NOT (job_id IS NULL) 
ORDER BY employee_id; 

SELECT * 
FROM employees 
WHERE NOT 
(salary BETWEEN 1000 AND 2000) 
ORDER BY employee_id; 


Type of 


Condition Operation Examples 


Returns TRUE if both component 


AND conditions are TRUE. SELECT * 
Returns FALSE if either is FALSE. 
Otherwise returns UNKNOWN. FROM employees 


WHERE job_id = 'PU_CLERK' 


AND department_id = 30 
ORDER BY employee_id; 


Returns TRUE if either component 


OR condition is TRUE. Returns FALSE if SELECT * 
both are FALSE. Otherwise 
returns UNKNOWN. FROM employees 


WHERE job_id = 'PU_CLERK' 
OR department_id = 10 
ORDER BY employee_id; 


NOT Truth Table 
-- TRUE FALSE UNKNOWN 
NOT FALSE TRUE UNKNOWN 
AND Truth Table 
AND TRUE FALSE UNKNOWN 
TRUE TRUE FALSE UNKNOWN 
FALSE FALSE FALSE FALSE 
UNKNOWN UNKNOWN FALSE UNKNOWN 


For example, in the WHERE clause of the following SELECT statement, the AND logical condition is used to 
ensure that only those hired before 2004 and earning more than $2500 a month are returned: 


SELECT * FROM employees 

WHERE hire_date < TO_DATE(‘01-JAN-2004', 'DD-MON-YYYY’') 
AND salary > 2500 
ORDER BY employee_id; 


OR Truth Table 


OR TRUE FALSE UNKNOWN 


TRUE TRUE TRUE TRUE 
FALSE TRUE FALSE UNKNOWN 
UNKNOWN TRUE UNKNOWN UNKNOWN 


For example, the following query returns employees who have a 40% commission rate or a salary greater than 
$20,000: 


SELECT employee_id FROM employees 
WHERE commission_pct = .4 OR salary > 20000 
ORDER BY employee_id; 


Model Conditions 


Model conditions can be used only in the MODEL clause of a SELECT statement. 


IS ANY Condition 


The IS ANY condition can be used only in the model_clause of a SELECT statement. Use this condition to 
qualify all values of a dimension column, including NULL. 


The condition always returns a Boolean value of TRUE in order to qualify all values of the column. 
Example 


The following example sets sales for each product for year 2000 to 0: 


SELECT country, prod, year, s 

FROM sales_view_ref 

MODEL 
PARTITION BY (country) 
DIMENSION BY (prod, year) 
MEASURES (sale s) 
IGNORE NAV 
UNIQUE DIMENSION 
RULES UPSERT SEQUENTIAL ORDER 


s[ANY, 2000] = 0 


) 
ORDER BY country, prod, year; 


COUNTRY PROD YEAR S 
France Mouse Pad 1998 2509.42 
France Mouse Pad 1999 3678.69 
France Mouse Pad 2000 0 
France Mouse Pad 2001 3269.09 
France Standard Mouse 1998 2390.83 
France Standard Mouse 1999 2280.45 
France Standard Mouse 2000 0 
France Standard Mouse 2001 2164.54 


Germany Mouse Pad 1998 5827.87 


Germany Mouse Pad 1999 8346.44 


Germany Mouse Pad 2000 0 
Germany Mouse Pad 2001 9535.08 
Germany Standard Mouse 1998 7116.11 
Germany Standard Mouse 1999 6263.14 
Germany Standard Mouse 2000 0 
Germany Standard Mouse 2001 6456.13 


16 rows selected. 


IS PRESENT Condition 


The IS PRESENT condition can be used only in the model_clause of a SELECT statement. Use this condition to 
test whether the cell referenced is present prior to the execution of the model_clause . 


The condition returns TRUE if the cell exists prior to the execution of the model_clause and FALSE if it does not. 
Example 


In the following example, if sales of the Mouse Pad for year 1999 exist, then sales of the Mouse Pad for year 2000 
is set to sales of the Mouse Pad for year 1999. Otherwise, sales of the Mouse Pad for year 2000 is set to 0. 


SELECT country, prod, year, s 

FROM sales_view_ref 

MODEL 
PARTITION BY (country) 
DIMENSION BY (prod, year) 
MEASURES (sale s) 
IGNORE NAV 
UNIQUE DIMENSION 
RULES UPSERT SEQUENTIAL ORDER 


s['Mouse Pad', 2000] = 
CASE WHEN s["Mouse Pad’, 1999] IS PRESENT 
THEN s['Mouse Pad’, 1999] 
ELSE 0 
END 


) 
ORDER BY country, prod, year; 


COUNTRY PROD YEAR S 
France Mouse Pad 1998 2509.42 
France Mouse Pad 1999 3678.69 
France Mouse Pad 2000 3678.69 
France Mouse Pad 2001 3269.09 
France Standard Mouse 1998 2390.83 
France Standard Mouse 1999 2280.45 
France Standard Mouse 2000 1274.31 
France Standard Mouse 2001 2164.54 
Germany Mouse Pad 1998 5827.87 
Germany Mouse Pad 1999 8346.44 
Germany Mouse Pad 2000 8346.44 
Germany Mouse Pad 2001 9535.08 
Germany Standard Mouse 1998 7116.11 


Germany Standard Mouse 1999 6263.14 


Germany Standard Mouse 2000 2637.31 
Germany Standard Mouse 2001 6456.13 
16 rows selected. 


Multiset Conditions 


Multiset conditions test various aspects of nested tables. 


IS A SET Condition 


Use IS A SET conditions to test whether a specified nested table is composed of unique elements. The condition 
returns UNKNOWN if the nested table is NULL. Otherwise, it returns TRUE if the nested table is a set, even if it 
is a nested table of length zero, and FALSE otherwise. 


Example 


The following example selects from the table customers_demo those rows in which the cust_address_ntab nested 
table column contains unique elements: 


SELECT customer_id, cust_address_ntab 
FROM customers_ demo 
WHERE cust_address_ntab IS A SET 
ORDER BY customer_id; 


CUSTOMER_ID CUST_ADDRESS_NTAB(STREET_ADDRESS, POSTAL_CODE, CITY, 
STATE_PROVINCE, COUNTRY_ID) 
101 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘514 W Superior St’, '46901', 'Kokomo', 
'IN', 'US')) 
102 CUST_LADDRESS_TAB_TYP(CUST_ADDRESS_TYP('2515 Bloyd Ave’, '46218', ‘Indianapolis’, 
'IN', 'US')) 
103 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('8768 N State Rd 37', '47404', 
‘Bloomington’, 'IN', 'US')) 
104 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('6445 Bay Harbor Ln’, '46254', 
‘Indianapolis’, 'IN', 'US')) 
105 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP(‘4019 W 3Rd St’, '47404', ‘Bloomington’, 
‘IN’, 'US')) 


The preceding example requires the table customers_demo and a nested table column containing data. 


IS EMPTY Condition 


Use the IS [NOT] EMPTY conditions to test whether a specified nested table is empty. A nested table that consists 
of a single value, a NULL, is not considered an empty nested table. 


The condition returns a Boolean value: TRUE for an IS EMPTY condition if the collection is empty, and TRUE for 
an IS NOT EMPTY condition if the collection is not empty. If you specify NULL for the nested table or varray, 
then the result is NULL. 


Example 


The following example selects from the sample table pm.print_media those rows in which 
the ad_textdocs_ntab nested table column is not empty: 


SELECT product_id, TO_CHAR(ad_finaltext) AS text 
FROM print_media 
WHERE ad_textdocs_ntab IS NOT EMPTY 


ORDER BY product_id, text; 


MEMBER Condition 


A member_condition is a membership condition that tests whether an element is a member of a nested table. The 
return value is TRUE if expr is equal to a member of the specified nested table or varray. The return value 
is NULL if expr is null or if the nested table is empty. 


expr must be of the same type as the element type of the nested table. 
- The OF keyword is optional and does not change the behavior of the condition. 


The NOT keyword reverses the Boolean output: Oracle returns FALSE if expr is a member of the 
specified nested table. 


The element types of the nested table must be comparable. 
Example 


The following example selects from the table customers_demo those rows in which the cust_address_ntab nested 
table column contains the values specified in the WHERE clause: 


SELECT customer_id, cust_address_ntab 
FROM customers_demo 
WHERE cust_address_typ('8768 N State Rd 37', 47404, 
‘Bloomington’, 'IN', 'US') 
MEMBER OF cust_address_ntab 
ORDER BY customer_id; 


CUSTOMER_ID CUST_ADDRESS_NTAB(STREET_ADDRESS, POSTAL_CODE, CITY, 
STATE_PROVINCE, COUNTRY_ID) 


103 CUST_ADDRESS_TAB_TYP(CUST_ADDRESS_TYP('8768 N State Rd 37', '47404', 
‘Bloomington’, 'IN', 'US')) 


The preceding example requires the table customers_demo and a nested table column containing data. 


SUBMULTISET Condition 


The SUBMULTISET condition tests whether a specified nested table is a submultiset of another specified nested 
table. 


The operator returns a Boolean value. TRUE is returned when nested_table1 is asubmultiset of nested_table2 . 
nested_table1 is a submultiset of nested_table2 when one of the following conditions occur: 


nested_table1 is not null and contains no rows. TRUE is returned even if nested_table2 is null since an 
empty multiset is a submultiset of any non-null replacement for nested_table2 . 
- nested_table1 and nested_table2 are not null, nested_table1 does not contain a null element, and there is 
a one-to-one mapping of each element in nested_table1 to an equal element in nested_table2. 
NULL is returned when one of the following conditions occurs: 


- nested_tablel is null. 
nested_table2 is null, and nested_table1 is not null and not empty. 


nested_table1 is a submultiset of nested_table2 after modifying each null element of nested_table1 and 
nested_table2 to some non-null value, enabling a one-to-one mapping of each element in nested_table1 
to an equal element in nested_table2. 


If none of the above conditions occur, then FALSE is returned. 
Example 


The following example selects from the customers_demo table those rows in which the cust_address_ntab nested 
table is a submultiset of the cust_address2_ntab nested table: 


SELECT customer_id, cust_address_ntab 
FROM customers_demo 
WHERE cust_address_ntab SUBMULTISET OF cust_address2_ntab 
ORDER BY customer_id; 


The preceding example requires the table customers_demo and two nested table columns containing data. 
Pattern-matching Conditions 


The pattern-matching conditions compare character data. 


LIKE Condition 


The LIKE conditions specify a test involving pattern matching. Whereas the equality operator (=) exactly matches 
one character value to another, the LIKE conditions match a portion of one character value to another by searching 
the first value for the pattern specified by the second. LIKE calculates strings using characters as defined by the 
input character set. LIKEC uses Unicode complete characters. LIKE2 uses UCS2 code points. LIKE4 uses UCS4 
code points. 


The LIKE condition is the best choice in almost all situations. Use the following guidelines to determine whether 
any of the variations would be helpful in your environment: 


Use LIKE2 to process strings using UCS-2 semantics. LIKE2 treats a Unicode supplementary character as 
two characters. 


Use LIKE4 to process strings using UCS-4 semantics. LIKE4 treats a Unicode supplementary character as 
one character. 


Use LIKEC to process strings using Unicode complete character semantics. LIKEC treats a composite 
character as one character. 


If esc_char is not specified, then there is no default escape character. If any of char1 , char2, or esc_char is 
null, then the result is unknown. Otherwise, the escape character, if specified, must be a character string of length 
1. 


All of the character expressions ( char1 , char2 , and esc_char ) can be of any of the data 
types CHAR, VARCHAR2, NCHAR, or NVARCHAR2. If they differ, then Oracle converts all of them to the data 
type of char1 . 


The pattern can contain special pattern-matching characters: 


- An underscore (_) in the pattern matches exactly one character (as opposed to one byte in a multibyte 
character set) in the value. 


A percent sign (%) in the pattern can match zero or more characters (as opposed to bytes in a multibyte 
character set) in the value. The pattern '%' cannot match a null. 


You can include the actual characters % or _ in the pattern by using the ESCAPE clause, which identifies the 
escape character. If the escape character precedes the character % or _ in the pattern, then Oracle interprets this 
character literally in the pattern rather than as a special pattern-matching character. You can also search for the 
escape character itself by repeating it. For example, if @ is the escape character, then you can use @@ to search 


for @. 
LIKE Condition 


Type of 


Condition Operation Example 


TRUE if x does [not] match the pattern y. 


x [NOT] Within y , the character % matches any string SELECT last name 
LIKE y of zero or more characters except null. The 7 
character _ matches any single character. Any FROM employees 
[ESCAPE character can follow ESCAPE except percent 
'z'] (%) and underbar (_). A wildcard character is WHERE last_name 
treated as a literal if preceded by the escape LIKE '%A\ B%' ESCAPE '\ 
character. 


ORDER BY last_name; 


To process the LIKE conditions, Oracle divides the pattern into subpatterns consisting of one or two characters 
each. The two-character subpatterns begin with the escape character and the other character is %, or _, or the 
escape character. 


LetP,,P ,,..., P „ be these subpatterns. The like condition is true if there is a way to partition the search value 
into substrings S,,5,,...,S,, so that for all i between 1 and n: 


If P; is_, then S, is a single character. 
If P; is %, then S; is any string. 

- IfP, is two characters beginning with an escape character, then S ; is the second character of P ;. 
Otherwise, P; =S,. 


With the LIKE conditions, you can compare a value to a pattern rather than to a constant. The pattern must appear 
after the LIKE keyword. For example, you can issue the following query to find the salaries of all employees with 
names beginning with R: 


SELECT salary 
FROM employees 
WHERE last_name LIKE 'R%' 
ORDER BY salary; 


The following query uses the = operator, rather than the LIKE condition, to find the salaries of all employees with 
the name 'R%': 


SELECT salary 
FROM employees 
WHERE last_name = 'R%' 
ORDER BY salary; 


The following query finds the salaries of all employees with the name 'SM%'. Oracle interprets 'SM%' as a text 
literal, rather than as a pattern, because it precedes the LIKE keyword: 


SELECT salary 
FROM employees 
WHERE 'SM%' LIKE last_name 
ORDER BY salary; 


Collation and Case Sensitivity 


The LIKE condition is collation-sensitive. Oracle Database compares the subpattern Pi to the substring Si in the 
processing algorithm above using the collation determined from the derived collations of char1 and char2 . If 
this collation is case-insensitive, the pattern-matching is case-insensitive as well. 


Pattern Matching on Indexed Columns 


When you use LIKE to search an indexed column for a pattern, Oracle can use the index to improve performance 
of a query if the leading character in the pattern is not % or _. In this case, Oracle can scan the index by this 
leading character. If the first character in the pattern is % or _, then the index cannot improve performance because 
Oracle cannot scan the index. 


LIKE Condition: General Examples 


This condition is true for all last_name values beginning with Ma: 


last_name LIKE 'Ma%' 


All of these last_name values make the condition true: 


Mallin, Markle, Marlow, Marvins, Mavris, Matos 


Case is significant, so last_name values beginning with MA, ma, and mA make the condition false. 


Consider this condition: 


last_name LIKE 'SMITH_' 


This condition is true for these last_name values: 


SMITHE, SMITHY, SMITHS 


This condition is false for SMITH because the special underscore character (_) must match exactly one character 
of the last_name value. 


ESCAPE Clause Example 


The following example searches for employees with the pattern A_B in their name: 


SELECT last_name 
FROM employees 
WHERE last_name LIKE '%A\_B%' ESCAPE ‘\' 
ORDER BY last_name; 


The ESCAPE clause identifies the backslash (\) as the escape character. In the pattern, the escape character 
precedes the underscore (_). This causes Oracle to interpret the underscore literally, rather than as a special pattern 
matching character. 


Patterns Without % Example 


If a pattern does not contain the % character, then the condition can be true only if both operands have the same 
length. Consider the definition of this table and the values inserted into it: 


CREATE TABLE ducks (f CHAR(6), v VARCHAR2(6)); 
INSERT INTO ducks VALUES (‘DUCK’, 'DUCK'’); 
SELECT '*"|[f||'*" "char", 

"*'[ly||'*" "varchar" 

FROM ducks; 


char varchar 


*DUCK * *DUCK* 


Because Oracle blank-pads CHAR values, the value of f is blank-padded to 6 bytes. v is not blank-padded and has 
length 4. 


REGEXP_LIKE Condition 


REGEXP_LIKE is similar to the LIKE condition, except REGEXP_LIKE performs regular expression matching 
instead of the simple pattern matching performed by LIKE. This condition evaluates strings using characters as 
defined by the input character set. 


Similar to the LIKE condition, the REGEXP_LIKE condition is collation-sensitive. 
Examples 


The following query returns the first and last names for those employees with a first name of Steven or Stephen 
(where first_name begins with Ste and ends with en and in between is either v or ph): 


SELECT first_name, last_name 

FROM employees 

WHERE REGEXP_LIKE (first_name, '\Ste(v|ph)en$') 
ORDER BY first_name, last_name; 


FIRST_NAME LAST_NAME 
Steven King 

Steven Markle 

Stephen Stiles 


The following query returns the last name for those employees with a double vowel in their last name 
(where last_name contains two adjacent occurrences of either a, e, i, 0, or u, regardless of case): 


SELECT last_name 

FROM employees 

WHERE REGEXP_LIKE (last_name, '([aeiou])\1', ‘i') 
ORDER BY last_name; 


LAST_NAME 
De Haan 
Greenberg 
Khoo 

Gee 

Greene 

Lee 

Bloom 


Feeney 


Null Conditions 


A NULL condition tests for nulls. This is the only condition that you should use to test for nulls. 


Null Condition 
Type of 
Condition Operation Example 
Tests for nulls. 
IS [NOT] SELECT last_name 
NULL 


FROM employees 
WHERE commission_pct 
IS NULL 


ORDER BY last_name; 


XML Conditions 


XML conditions determine whether a specified XML resource can be found in a specified path. 


EQUALS _PATH Condition 


The EQUALS_PATH condition determines whether a resource in the Oracle XML database can be found in the 
database at a specified path. 


Use this condition in queries to RESOURCE_VIEW and PATH_VIEW. These public views provide a mechanism 
for SQL access to data stored in the XML database repository. RESOURCE_VIEW contains one row for each 
resource in the repository, and PATH_VIEW contains one row for each unique path in the repository. 


Example 


The view RESOURCE_VIEW computes the paths (in the any_path column) that lead to all XML resources (in 

the res column) in the database repository. The following example queries the RESOURCE_VIEW view to find 
the paths to the resources in the sample schema oe. The EQUALS_PATH condition causes the query to return only 
the specified path: 


SELECT ANY_PATH FROM RESOURCE_VIEW 
WHERE EQUALS_PATH(res, '/sys/schemas/OE/www.example.com')=1; 


ANY_PATH 


/sys/schemas/OE/www.example.com 


UNDER_PATH Condition 


The UNDER_PATH condition determines whether resources specified in a column can be found under a particular 
path specified by path_string in the Oracle XML database repository. The path information is computed by 
the RESOURCE_VIEW view, which you query to use this condition. 


Use this condition in queries to RESOURCE_VIEW and PATH_VIEW. These public views provide a mechanism 
for SQL access to data stored in the XML database repository. RESOURCE_VIEW contains one row for each 


resource in the repository, and PATH_VIEW contains one row for each unique path in the repository. 
Example 


The view RESOURCE_VIEW computes the paths (in the any_path column) that lead to all XML resources (in 
the res column) in the database repository. The following example queries the RESOURCE_VIEW view to find 
the paths to the resources in the sample schema oe. The query returns the path of the XML schema: 


SELECT ANY_PATH FROM RESOURCE_VIEW 
WHERE UNDER_PATH(res, '/sys/schemas/OE/www.example.com')=1; 


ANY_PATH 


/sys/schemas/OE/www.example.com/xwarehouses.xsd 


SQL/JSON Conditions 
SQL/JSON conditions allow you to test JavaScript Object Notation (JSON) data as follows: 
IS JSON Condition lets you test whether an expression is syntactically correct JSON data 
JSON_EXISTS Condition lets you test whether a specified JSON value exists in JSON data 
e JSON_TEXTCONTAINS Condition lets you test whether a specified character string exists in JSON 


property values. 


IS JSON Condition 
Use this SQL/JSON condition to test whether an expression is syntactically correct, or well-formed, JSON data. 


- Ifyou specify IS JSON, then this condition returns TRUE if the expression is well-formed JSON data 
and FALSE if the expression is not well-formed JSON data. 


If you specify IS NOT JSON, then this condition returns TRUE if the expression is not well-formed JSON 
data and FALSE if the expression is well-formed JSON data. 
Examples 


Testing for STRICT or LAX JSON Syntax: Example 


The following statement creates table t with column coll: 
CREATE TABLE t (coll VARCHAR2(100)); 
The following statements insert values into column col1 of table t: 


INSERT INTO t VALUES ('[ "LIT192", "CS141", "HIS160" J' ); 

INSERT INTO t VALUES ('{ "Name": "John" }' ); 

INSERT INTO t VALUES ('{ "Grade Values" : { A : 4.0, B : 3.0, C : 2.0 } }'; 
INSERT INTO t VALUES ('{ "isEnrolled" : true }' ); 

INSERT INTO t VALUES ('{ "isMatriculated" : False }' ); 

INSERT INTO t VALUES (NULL); 

INSERT INTO t VALUES (This is not well-formed JSON data’); 


The following statement queries table t and returns coll values that are well-formed JSON data. Because neither 
the STRICT nor LAX keyword is specified, this example uses the default LAX setting. Therefore, this query 
returns values that use strict or lax JSON syntax. 


SELECT coll 
FROM +t 
WHERE coll IS JSON; 


[ "LIT192", "CS141", "HIS160" ] 

{ "Name": "John" } 

{ "Grade Values": { A: 4.0, B: 3.0, C: 2.0 } } 
{ "isEnrolled" : true } 

{ "isMatriculated" : False } 


The following statement queries table t and returns coll values that are well-formed JSON data. This example 
specifies the STRICT setting. Therefore, this query returns only values that use strict JSON syntax. 


SELECT coll 
FROM t 
WHERE colli IS JSON STRICT; 


[ "LIT192", "CS141", "HIS160" ] 
{ "Name": "John" } 
{ "isEnrolled" : true } 


The following statement queries table t and returns coll values that use lax JSON syntax, but omits coll values 
that use strict JSON syntax. Therefore, this query returns only values that contain the exceptions allowed in lax 
JSON syntax. 


SELECT coll 
FROM t 
WHERE coll IS NOT JSON STRICT AND coli IS JSON LAX; 


{ "Grade Values": { A: 4.0, B: 3.0, C: 2.0 } } 
{ "isMatriculated" : False } 


Testing for Unique Keys: Example 


The following statement creates table t with column coll: 
CREATE TABLE t (coll VARCHAR2(100)); 
The following statements insert values into column col1 of table t: 


INSERT INTO t VALUES (‘{a:100, b:200, c:300}'); 
INSERT INTO t VALUES (‘{a:100, a:200, b:300}'); 
INSERT INTO t VALUES (‘{a:100, b : {a:100, c:300}}'); 


The following statement queries table t and returns coll values that are well-formed JSON data with unique key 
names within each object: 


SELECT coll FROM t 
WHERE coll IS JSON WITH UNIQUE KEYS; 


{a:100, b:200, c:300} 
{a:100, b : {a:100, c:300}} 


The second row is returned because, while the key name a appears twice, it is in two different objects. 


The following statement queries table t and returns coll values that are well-formed JSON data, regardless of 
whether there are unique key names within each object: 


SELECT coll FROM t 
WHERE coll IS JSON WITHOUT UNIQUE KEYS; 


{a:100, b:200, c:300} 
{a:100, a:200, b:300} 
{a:100, b : {a:100, c:300}} 


Using IS JSON as a Check Constraint: Example 


The following statement creates table j_purchaseorder, which will store JSON data in column po_document. The 
statement uses the IS JSON condition as a check constraint to ensure that only well-formed JSON is stored in 
column po_document. 


CREATE TABLE j_purchaseorder 
(id RAW (16) NOT NULL, 
date_loaded TIMESTAMP(6) WITH TIME ZONE, 
po_document CLOB CONSTRAINT ensure_json CHECK (po_document IS JSON)); 


JSON_EQUAL Condition 


The Oracle SQL condition JSON_EQUAL compares two JSON values and returns true if they are equal. It returns 
false if the two values are not equal. The input values must be valid JSON data. 


The comparison ignores insignificant whitespace and insignificant object member order. For 
example, JSON objects are equal, if they have the same members, regardless of their order. 


If either of the two compared inputs has one or more duplicate fields, then the value returned by JSON_EQUAL is 
unspecified. 


JSON_EQUAL supports ERROR ON ERROR, FALSE ON ERROR, and TRUE ON ERROR. The default 
is FALSE ON ERROR. A typical example of an error is when the input expression is not valid JSON. 


Examples 


The following statements return TRUE: 


JSON_EQUAL(‘{}', '{ }') 
JSON_EQUAL(‘{a:1, b:2}', '{b:2 , a:1 }) 


The following statement return FALSE: 


JSON_EQUAL(‘{a:"1"}', '{a:1 }') -> FALSE 


The following statement results ina ORA-40441 JSON syntax error 


JSON_EQUAL(T1]’, '[}' ERROR ON ERROR) 


JSON_EXISTS Condition 


Use the SQL/JSON condition JSON_EXISTS to test whether a specified JSON value exists in JSON data. This 
condition returns TRUE if the JSON value exists and FALSE if the JSON value does not exist. 


expr 


Use this clause to specify the JSON data to be evaluated. For expr , specify an expression that evaluates to a text 
literal. If expr is a column, then the column must be of data type VARCHAR2, CLOB, or BLOB. If expr 
evaluates to null or a text literal of length zero, then the condition returns UNKNOWN. 


If expr is not a text literal of well-formed JSON data using strict or lax syntax, then the condition 
returns FALSE by default. You can use the JSON_exists_on_error_clause to override this default behavior. 


FORMAT JSON 
You must specify FORMAT JSON if expr is a column of data type BLOB. 
JSON_basic_path_expression 


Use this clause to specify a SQL/JSON path expression. The condition uses the path expression to evaluate expr 
and determine if a JSON value that matches, or satisfies, the path expression exists. The path expression must be a 
text literal, but it can contain variables whose values are passed to the path expression by the 
JSON_passing_clause . 


JSON_passing_clause 


Use this clause to pass values to the path expression. For expr , specify a value of data 
type VARCHAR2, NUMBER, BINARY_DOUBLE, DATE, TIMESTAMP, or TIMESTAMP WITH TIME ZONE. 
The result of evaluating expr is bound to the corresponding identifier in the JSON_basic_path_expression . 


JSON_exists_on_error_clause 


Use this clause to specify the value returned by this condition when expr is not well-formed JSON data. 
You can specify the following clauses: 


ERROR ON ERROR - Returns the appropriate Oracle error when expr is not well-formed JSON data. 
e TRUE ON ERROR - Returns TRUE when expr is not well-formed JSON data. 
FALSE ON ERROR - Returns FALSE when expr is not well-formed JSON data. This is the default. 


JSON_exists_on_empty_clause 


Use this clause to specify the value returned by this function if no match is found when the JSON data is evaluated 
using the SQL/JSON path expression. This clause allows you to specify a different outcome for this type of error 


than the outcome specified with the JSON_exists_on_error_clause. 


You can specify the following clauses: 


e NULL ON EMPTY - Returns null when no match is found. 
ERROR ON EMPTY - Returns the appropriate Oracle error when no match is found. 


DEFAULT literal ON EMPTY - Returns literal when no match is found. The data type of literal must 
match the data type of the value returned by this function. 


If you omit this clause, then the JSON_exists_on_error_clause determines the value returned when no match is 
found. 


Examples 


The following statement creates table t with column name: 


CREATE TABLE t (name VARCHAR2(100)); 


The following statements insert values into column name of table t: 


INSERT INTO t VALUES ([{first:"John"}, {middle:"Mark"}, {last:"Smith"}]'); 
INSERT INTO t VALUES ([{first:"Mary"}, {last:"Jones"}]'); 

INSERT INTO t VALUES ([{first:"Jeff"}, {last:"Williams"}]'); 

INSERT INTO t VALUES ([{first:"Jean"}, {middle:"Anne"}, {last:"Brown"}]'); 
INSERT INTO t VALUES (NULL); 

INSERT INTO t VALUES (This is not well-formed JSON data’); 


The following statement queries column name in table t and returns JSON data that consists of an array whose first 
element is an object with property name first. The ON ERROR clause is not specified. Therefore, 
the JSON_EXISTS condition returns FALSE for values that are not well-formed JSON data. 


SELECT name FROM t 
WHERE JSON_EXISTS(name, '$[0].first'); 


[{first:"John"}, {middle:"Mark"}, {last:"Smith"}] 
[{first:"Mary"}, {last:"Jones"}] 

[{first:"Jeff"}, {last: "Williams" }] 

[{first:"Jean"}, {middle:"Anne"}, {last:"Brown"}] 


The following statement queries column name in table t and returns JSON data that consists of an array whose 
second element is an object with property name middle. The ON ERROR clause is not specified. Therefore, 
the JSON_EXISTS condition returns FALSE for values that are not well-formed JSON data. 


SELECT name FROM t 
WHERE JSON_EXISTS(name, '$[1].middle'); 


[{first:"John"}, {middle:"Mark"}, {last:"Smith"}] 
[{first:"Jean"}, {middle:"Anne"}, {last:"Brown"}] 


The following statement is similar to the previous statement, except that the TRUE ON ERROR clause is 
specified. Therefore, the JSON_EXISTS condition returns TRUE for values that are not well-formed JSON data. 


SELECT name FROM t 
WHERE JSON_EXISTS(name, '$[1].middle' TRUE ON ERROR); 


[{first:"John"}, {middle:"Mark"}, {last:"Smith"}] 
[{first:"Jean"}, {middle:"Anne"}, {last:"Brown"}] 
This is not well-formed JSON data 


The following statement queries column name in table t and returns JSON data that consists of an array that 
contains an element that is an object with property name last. The wildcard symbol (*) is specified for the array 
index. Therefore, the query returns arrays that contain such an object, regardless of its index number in the array. 


SELECT name FROM t 
WHERE JSON_EXISTS(name, '$[*].last'); 


[{first:"John"}, {middle:"Mark"}, {last:"Smith"}] 
[{first:"Mary"}, {last:"Jones"}] 

[{first:"Jeff"}, {last:"Williams"}] 

[{first:"Jean"}, {middle:"Anne"}, {last:"Brown"}] 


JSON_TEXTCONTAINS Condition 


Use the SQL/JSON condition JSON_TEXTCONTAINS to test whether a specified character string exists in JSON 
property values. You can use this condition to filter JSON data on a specific word or number. 


This condition takes the following arguments: 


A table or view column that contains JSON data. A JSON search index, which is an Oracle Text index 
designed specifically for use with JSON data, must be defined on the column. Each row of JSON data in 
the column is referred to as a JSON document. 


e ASQL/JSON path expression. The path expression is applied to each JSON document in an attempt to 
match a specific JSON object within the document. The path expression can contain only JSON object 
steps; it cannot contain JSON array steps. 


A character string. The condition searches for the character string in all of the string and numeric property 
values in the matched JSON object, including array values. The string must exist as a separate word in the 
property value. For example, if you search for ‘beth’, then a match will be found for string property value 
"beth smith", but not for "elizabeth smith". If you search for '10', then a match will be found for numeric 
property value 10 or string property value "10 main street", but a match will not be found for numeric 
property value 110 or string property value "102 main street". 


This condition returns TRUE if a match is found, and FALSE if a match is not found. 
column 


Specify the name of the table or view column containing the JSON data to be tested. The column must be of data 
type VARCHAR2, CLOB, or BLOB. A JSON search index, which is an Oracle Text index designed specifically 
for use with JSON data, must be defined on the column. If a column value is a null or a text literal of length zero, 
then the condition returns UNKNOWN. 


If a column value is not a text literal of well-formed JSON data using strict or lax syntax, then the condition 
returns FALSE. 


JSON_basic_path_expression 


Use this clause to specify a SQL/JSON path expression. The condition uses the path expression to evaluate 
column and determine if a JSON value that matches, or satisfies, the path expression exists. The path expression 
must be a text literal. 


string 


The condition searches for the character string specified by string . The string must be enclosed in single 
quotation marks. 


Examples 


The following statement creates table families with column family_doc: 


CREATE TABLE families (family_doc VARCHAR2(200)); 


The following statement creates a JSON search index on column family_doc: 


CREATE INDEX ix 
ON families(family_doc) 
INDEXTYPE IS CTXSYS.CONTEXT 
PARAMETERS (‘SECTION GROUP CTXSYS.JSON_SECTION_GROUP SYNC (ON COMMIT)’; 


The following statements insert JSON documents that describe families into column family_doc: 


INSERT INTO families 
VALUES (‘{family : {id:10, ages:[40,38,12], address : {street : "10 Main Street"}}}"'); 


INSERT INTO families 
VALUES (‘{family : {id:11, ages:[42,40,10,5], address : {street : "200 East Street", apt : 20}}}'); 


INSERT INTO families 
VALUES (‘{family : {id:12, ages:[25,23], address : {street : "300 Oak Street", apt : 10}}}'); 


The following statement commits the transaction: 


COMMIT; 


The following query returns the JSON documents that contain 10 in any property value in the document: 


SELECT family_doc FROM families 
WHERE JSON_TEXTCONTAINS(family_doc, '$', '10'); 


FAMILY_DOC 

{family : {id:10, ages:[40,38,12], address : {street : "10 Main Street"}}} 

{family : {id:11, ages:[42,40,10,5], address : {street : "200 East Street", apt : 20}}} 
{family : {id:12, ages:[25,23], address : {street : "300 Oak Street", apt : 10}}} 


The following query returns the JSON documents that contain 10 in the id property value: 


SELECT family_doc FROM families 
where json_textcontains(family_doc, '$.family.id', '10'); 


FAMILY _DOC 


{family : {id:10, ages:[40,38,12], address : {street : "10 Main Street" }}} 


The following query returns the JSON documents that have a 10 in the array of values for the ages property: 


SELECT family_doc FROM families 
WHERE JSON_TEXTCONTAINS(family_doc, '$.family.ages', '10'); 


FAMILY _DOC 


{family : {id:11, ages:[42,40,10,5], address : {street : "200 East Street", apt : 20}}} 


The following query returns the JSON documents that have a 10 in the address property value: 


SELECT family_doc FROM families 
WHERE JSON_TEXTCONTAINS(family_doc, '$.family.address', '10'); 


FAMILY _DOC 


{family : {id:10, ages:[40,38,12], address : {street : "10 Main Street"}}} 
{family : {id:12, ages:[25,23], address : {street : "300 Oak Street", apt : 10}}} 


The following query returns the JSON documents that have a 10 in the apt property value: 


SELECT family_doc FROM families 
WHERE JSON_TEXTCONTAINS(family_doc, '$.family.address.apt', '10'); 


FAMILY _DOC 


{family : {id:12, ages:[25,23], address : {street : "300 Oak Street", apt : 10}}} 


Compound Conditions 


A compound condition specifies a combination of other conditions. 


BETWEEN Condition 


A BETWEEN condition determines whether the value of one expression is in an interval defined by two other 
expressions. 


All three expressions must be numeric, character, or datetime expressions. In SQL, it is possible that expr1 will 
be evaluated more than once. If the BETWEEN expression appears in PL/SQL, expr1 is guaranteed to be 
evaluated only once. If the expressions are not all the same data type, then Oracle Database implicitly converts the 
expressions to a common data type. If it cannot do so, then it returns an error. 


The value of 


exprl NOT BETWEEN expr2 AND expr3 
is the value of the expression 
NOT (exprl BETWEEN expr2 AND expr3) 
And the value of 
exprl BETWEEN expr2 AND expr3 
is the value of the boolean expression: 
expr2 <= exprl AND expr1 <= expr3 
If expr3 < expr2, then the interval is empty. If expr1 is NULL, then the result is NULL. If expr1 is not NULL, 


then the value is FALSE in the ordinary case and TRUE when the keyword NOT is used. 


The boolean operator AND may produce unexpected results. Specifically, in the expression x AND y, the 
condition x IS NULL is not sufficient to determine the value of the expression. The second operand still must be 
evaluated. The result is FALSE if the second operand has the value FALSE and NULL otherwise. 


BETWEEN Condition 


Type of 
Condition Operation Example 
[NOT] ( expr2 less than or equal to 
[NOT] expri AND expr1 less than or equal SELECT * FROM employees 
BETWEEN to expr3 ) 
x AND y WHERE salary 


BETWEEN 2000 AND 3000 


ORDER BY employee_id; 


EXISTS Condition 


An EXISTS condition tests for existence of rows in a subquery. 


EXISTS Condition 


Type of 
Condition Operation Example 


Type of 


Condition Operation Example 


TRUE if a subquery retums at least 


EXISTS one row. SELECT department_id 


FROM departments d 
WHERE EXISTS 


(SELECT * FROM employees e 


WHERE d.department_id 
= e.department_id) 


ORDER BY department_id; 
IN Condition 


An in_condition is amembership condition. It tests a value for membership in a list of values or subquery 


If you use the upper form of the in_condition condition (with a single expression to the left of the operator), then 
you must use the upper form of expression_list . If you use the lower form of this condition (with multiple 
expressions to the left of the operator), then you must use the lower form of expression_list , and the expressions 
in each expression_list must match in number and data type the expressions to the left of the operator. You can 
specify up to 1000 expressions in expression_list . 


Oracle Database does not always evaluate the expressions in an expression_list in the order in which they appear 
in the IN list. However, expressions in the select list of a subquery are evaluated in their specified order. 


IN Condition 


Type of Condition Operation Example 


Equal-to-any-member-of test. 
IN Equivalent to =ANY. SELECT * FROM employees 


WHERE job_id IN 

(‘PU_CLERK','SH_CLERK'’) 

ORDER BY employee_id; 
SELECT * FROM employees 

WHERE salary IN 

(SELECT salary 

FROM employees 

WHERE department_id =30) 


ORDER BY employee_id; 


Type of Condition Operation Example 


Equivalent to !=ALL. Evaluates 
NOT IN to FALSE if any member of the set SELECT * FROM employees 
is NULL. 
WHERE salary NOT IN 


(SELECT salary 

FROM employees 

WHERE department_id = 30) 

ORDER BY employee_id; 
SELECT * FROM employees 

WHERE job_id NOT IN 

(‘PU_CLERK', 'SH_CLERK') 

ORDER BY employee_id; 


If any item in the list following a NOT IN operation evaluates to null, then all rows evaluate 
to FALSE or UNKNOWN, and no rows are returned. For example, the following statement returns the string 'True' 
for each row: 


SELECT 'True' FROM employees 
WHERE department_id NOT IN (10, 20); 


However, the following statement returns no rows: 


SELECT 'True' FROM employees 
WHERE department_id NOT IN (10, 20, NULL); 


The preceding example returns no rows because the WHERE clause condition evaluates to: 
department_id != 10 AND department_id != 20 AND department_id != null 


Because the third condition compares department_id with a null, it results in an UNKNOWN, so the entire 
expression results in FALSE (for rows with department_id equal to 10 or 20). This behavior can easily be 
overlooked, especially when the NOT IN operator references a subquery. 


Moreover, if a NOT IN condition references a subquery that returns no rows at all, then all rows will be returned, 
as shown in the following example: 


SELECT 'True' FROM employees 
WHERE department_id NOT IN (SELECT 0 FROM DUAL WHERE 1=2); 


For character arguments, the IN condition is collation-sensitive. The collation determination rules determine the 
collation to use. 


Restriction on LEVEL in WHERE Clauses 


In a [NOT] IN condition in a WHERE clause, if the right-hand side of the condition is a subquery, you cannot 
use LEVEL on the left-hand side of the condition. However, you can specify LEVEL in a subquery of 
the FROM clause to achieve the same result. For example, the following statement is not valid: 


SELECT employee_id, last_name FROM employees 
WHERE (employee_id, LEVEL) 
IN (SELECT employee_id, 2 FROM employees) 
START WITH employee_id = 2 
CONNECT BY PRIOR employee_id = manager_id; 


But the following statement is valid because it encapsulates the query containing the LEVEL information in 
the FROM clause: 


SELECT v.employee_id, v.last_name, v.lev FROM 
(SELECT employee_id, last_name, LEVEL lev 
FROM employees v 
START WITH employee_id = 100 
CONNECT BY PRIOR employee_id = manager_id) v 

WHERE (v.employee_id, v.lev) IN 
(SELECT employee_id, 2 FROM employees); 


IS OF type Condition 


Use the IS OF type condition to test object instances based on their specific type information. 


You must have EXECUTE privilege on all types referenced by type , and all type s must belong to the same type 


family. 


This condition evaluates to null if expr is null. If expr is not null, then the condition evaluates to true (or false if 


you specify the NOT keyword) under either of these circumstances: 


The most specific type of expr is the subtype of one of the types specified in the type list and you have 


not specified ONLY for the type, or 
- The most specific type of expr is explicitly specified in the type list. 


The expr frequently takes the form of the VALUE function with a correlation variable. 


The following example uses the sample table oe.persons. The example uses the IS OF type condition to restrict 
the query to specific subtypes: 


SELECT * FROM persons p 
WHERE VALUE(p) IS OF TYPE (employee_t); 


NAME SSN 
Joe 32456 
Tim 5678 


SELECT * FROM persons p 
WHERE VALUE(p) IS OF (ONLY part_time_emp_t); 


Functions 


Functions are similar to operators in that they manipulate data items and return a result. Functions differ from 
operators in the format of their arguments. This format enables them to operate on zero, one, two, or more 
arguments: 


function ( argument , argument, ...) 


A function without any arguments is similar to a pseudocolumn. However, a pseudocolumn typically returns a 
different value for each row in the result set, whereas a function without any arguments typically returns the same 
value for each row. 


This chapter contains these sections: 


- SQL Functions 


- Single-Row Functions 
o Numeric Functions 


o Character Functions Returning Character Values 
o Character Functions Returning Number Values 
o Character Set Functions 
e Collation Functions 
o Datetime Functions 
e General Comparison Functions 
o Conversion Functions 
e Large Object Functions 
e Collection Functions 
o Hierarchical Functions 
o Data Mining Functions 
o XML Functions 
o JSON Functions 
e Encoding and Decoding Functions 
e NULL-Related Functions 
o Environment and Identifier Functions 
- Aggregate Functions 
- Analytic Functions 
- Object Reference Functions 
- Model Functions 
- OLAP Functions 
- Data Cartridge Functions 
- About User-Defined Functions 


SQL Functions 


SQL functions are built into Oracle Database and are available for use in various appropriate SQL statements. Do 
not confuse SQL functions with user-defined functions written in PL/SQL. 


If you call a SQL function with an argument of a data type other than the data type expected by the SQL function, 
then Oracle attempts to convert the argument to the expected data type before performing the SQL function. 


Nulls in SQL Functions 


Most scalar functions return null when given a null argument. You can use the NVL function to return a value 
when a null occurs. For example, the expression NVL(commission_pct,0) returns 0 if commission_pct is null or 
the value of commission_pct if it is not null. 


Syntax for SQL Functions 


In the syntax diagrams for SQL functions, arguments are indicated by their data types. When the parameter 
function appears in SQL syntax, replace it with one of the functions described in this section. Functions are 
grouped by the data types of their arguments and their return values. 


Single-Row Functions 


Single-row functions return a single result row for every row of a queried table or view. These functions can 
appear in select lists, WHERE clauses, START WITH and CONNECT BY clauses, and HAVING clauses. 


Numeric Functions 


Numeric functions accept numeric input and return numeric values. Most numeric functions 

return NUMBER values that are accurate to 38 decimal digits. The transcendental 

functions COS, COSH, EXP, LN, LOG, SIN, SINH, SQRT, TAN, and TANH are accurate to 36 decimal digits. 
The transcendental functions ACOS, ASIN, ATAN, and ATAN2 are accurate to 30 decimal digits. The numeric 
functions are: 


ABS 
- ACOS 
- ASIN 
- ATAN 
e ATAN2 
- BITAND 
CEIL 
Cos 
COSH 
EXP 
FLOOR 
LN 
LOG 
- MOD 
e NANVL 
- POWER 
«e REMAINDER 
- ROUND (number) 
SIGN 
SIN 
SINH 
SQRT 
TAN 
TANH 
TRUNC (number) 
WIDTH_BUCKET 


Character Functions Returning Character Values 


Character functions that return character values return values of the following data types unless otherwise 
documented: 


If the input argument is CHAR or VARCHAR2, then the value returned is VARCHAR2. 
If the input argument is NCHAR or NVARCHAR2, then the value returned is NVARCHAR2. 


The length of the value returned by the function is limited by the maximum length of the data type returned. 


For functions that return CHAR or VARCHAR2, if the length of the return value exceeds the limit, then 
Oracle Database truncates it and returns the result without an error message. 


For functions that return CLOB values, if the length of the return values exceeds the limit, then Oracle 
raises an error and returns no data. 


The character functions that return character values are: 


CHR 
CONCAT 

«+ INITCAP 

- LOWER 

- LPAD 

- LTRIM 

- NCHR 
NLS_INITCAP 
NLS_LOWER 
NLS_UPPER 
NLSSORT 
REGEXP_REPLACE 
REGEXP_SUBSTR 


REPLACE 
- RPAD 
e RIRIM 
«e SOUNDEX 
- SUBSTR 


- TRANSLATE 
TRANSLATE ... USING 
TRIM 
UPPER 


Character Functions Returning Number Values 


Character functions that return number values can take as their argument any character data type. The character 
functions that return number values are: 


+ ASCII 
- INSTR 
- LENGTH 


e REGEXP_COUNT 
e REGEXP_INSTR 


Character Set Functions 


The character set functions return information about the character set. The character set functions are: 


NLS_CHARSET_DECL_LEN 
NLS_CHARSET_ID 
NLS_CHARSET_NAME 


Collation Functions 
The collation functions return information about collation settings. The collation functions are: 


COLLATION 
NLS_COLLATION_ID 
NLS_COLLATION_NAME 


Datetime Functions 


Datetime functions operate on date (DATE), timestamp (TIMESTAMP, TIMESTAMP WITH TIME ZONE, 
and TIMESTAMP WITH LOCAL TIME ZONE), and interval 
(INTERVAL DAY TO SECOND, INTERVAL YEAR TO MONTH) values. 


Some of the datetime functions were designed for the Oracle DATE data type 

(ADD_MONTHS, CURRENT_DATE, LAST_DAY, NEW_TIME, and NEXT_DAY). If you provide a timestamp 
value as their argument, then Oracle Database internally converts the input type to a DATE value and returns 

a DATE value. The exceptions are the MONTHS_BETWEEN function, which returns a number, and 

the ROUND and TRUNC functions, which do not accept timestamp or interval values at all. 


The remaining datetime functions were designed to accept any of the three types of data (date, timestamp, and 
interval) and to return a value of one of these types. 


All of the datetime functions that return current system datetime information, such 
as SYSDATE, SYSTIMESTAMP, CURRENT_TIMESTAMP, and so forth, are evaluated once for each SQL 
statement, regardless how many times they are referenced in that statement. 


The datetime functions are: 


ADD_MONTHS 

- CURRENT_DATE 

e CURRENT_TIMESTAMP 

e DBTIMEZONE 

- EXTRACT (datetime) 

«e FROM_TZ 
LAST_DAY 
LOCALTIMESTAMP 
MONTHS_BETWEEN 
NEW_TIME 
NEXT_DAY 
NUMTODSINTERVAL 
NUMTOYMINTERVAL 

e ORA_DST_AFFECTED 

«+ ORA_DST_CONVERT 

e ORA_DST_ERROR 

e ROUND (date) 

e SESSIONTIMEZONE 
SYS_EXTRACT_UTC 
SYSDATE 
SYSTIMESTAMP 
TO_CHAR (datetime) 
TO_DSINTERVAL 
TO_TIMESTAMP 
TO_TIMESTAMP_TZ 


TO_YMINTERVAL 
TRUNC (date) 
TZ_OFFSET 


General Comparison Functions 


The general comparison functions determine the greatest and or least value from a set of values. The general 
comparison functions are: 


GREATEST 
- LEAST 


Conversion Functions 


Conversion functions convert a value from one data type to another. Generally, the form of the function names 
follows the convention datatype TO datatype . The first data type is the input data type. The second data type is 
the output data type. The SQL conversion functions are: 


- ASCIISTR 

- BIN_TO_NUM 
CAST 
CHARTOROWID 
COMPOSE 
CONVERT 
DECOMPOSE 
HEXTORAW 
NUMTODSINTERVAL 

«e NUMTOYMINTERVAL 

«e RAWTOHEX 

« RAWTONHEX 

« ROWIDTOCHAR 

« ROWIDTONCHAR 
SCN_TO_TIMESTAMP 
TIMESTAMP_TO_SCN 
TO_BINARY_ DOUBLE 
TO_BINARY_ FLOAT 
TO_BLOB (bfile) 
TO_BLOB (raw) 
TO_CHAR (bfile|blob) 

e TO_CHAR (character) 

e TO_CHAR (datetime) 

e TO_CHAR (number) 

e TO_CLOB (bfile|blob) 

e TO_CLOB (character) 
TO_DATE 
TO_DSINTERVAL 
TO_LOB 
TO_MULTI BYTE 
TO_NCHAR (character) 
TO_NCHAR (datetime) 
TO_NCHAR (number) 

+ TO NCLOB 

- TO NUMBER 

- TO SINGLE BYTE 


TO_TIMESTAMP 
TO_TIMESTAMP_TZ 
TO_YMINTERVAL 

TREAT 

UNISTR 
VALIDATE_CONVERSION 


Large Object Functions 
The large object functions operate on LOBs. The large object functions are: 


- BFILENAME 
«e EMPTY_BLOB, EMPTY_CLOB 


Collection Functions 
The collection functions operate on nested tables and varrays. The SQL collection functions are: 


«e CARDINALITY 

e COLLECT 

+ POWERMULTISET 
POWERMULTISET_BY_CARDINALITY 
SET 


Hierarchical Functions 
Hierarchical functions applies hierarchical path information to a result set. The hierarchical function is: 


SYS_CONNECT_BY_PATH 


Data Mining Functions 


The data mining functions use Oracle Advanced Analytics to score data. The functions can apply a mining model 
schema object to the data, or they can dynamically mine the data by executing an analytic clause. The data mining 
functions can be applied to models built using the native algorithms of Oracle, as well as those built using R 
through the extensibility mechanism of Oracle Advanced Analytics. 


The data mining functions are: 


CLUSTER_DETAILS 
CLUSTER_DISTANCE 
CLUSTER_ID 
CLUSTER_PROBABILITY 
CLUSTER_SET 
FEATURE_COMPARE 

+ FEATURE_DETAILS 

e FEATURE_ID 

+ FEATURE _SET 

+ FEATURE VALUE 

+ ORA_DM_PARTITION_NAME 
PREDICTION 
PREDICTION_BOUNDS 
PREDICTION_COST 
PREDICTION_DETAILS 
PREDICTION_PROBABILITY 
PREDICTION_SET 


XML Functions 


The XML functions operate on or return XML documents or fragments. These functions use arguments that are not 
defined as part of the ANSI/ISO/IEC SQL Standard but are defined as part of the World Wide Web Consortium 
(W3C) standards. The processing and operations that the functions perform are defined by the relevant W3C 
standards. The table below provides a link to the appropriate section of the W3C standard for the rules and 
guidelines that apply to each of these XML-related arguments. A SQL statement that uses one of these XML 
functions, where any of the arguments does not conform to the relevant W3C syntax, will result in an error. Of 
special note is the fact that not every character that is allowed in the value of a database column is considered legal 
in XML. 


The SQL XML functions are: 


- DEPTH 
. EXISTSNODE 
» EXTRACT (XML) 
» EXTRACTVALUE 
. PATH 
SYS_DBURIGEN 
SYS_XMLAGG 
SYS_XMLGEN 
MLAGG 
MLCAST 
MLCDATA 
MLCOLATTVAL 
MLCOMMENT 
MLCONCAT 
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MLELEMENT 
LEXISTS 
LFOREST 
LISVALID 
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MLROOT 
MLSEQUENCE 
MLSERIALIZE 
MLTABLE 
MLTRANSFORM 


P< PS PI PS PS PS PS PS PS PS PS OS OS DS OS OX OX OX OX 


JSON Functions 
JavaScript Object Notation (JSON) functions allow you to query and generate JSON data. 
The following SQL/JSON functions allow you to query JSON data: 


. JSON_QUERY 
. JSON_TABLE 
JSON_VALUE 


The following SQL/JSON functions allow you to generate JSON data: 


JSON_ARRAY 
JSON_ARRAYAGG 
JSON_OBJECT 
JSON_OBJECTAGG 


The following Oracle SQL function creates a JSON data guide: 


JSON_DATAGUIDE 


Encoding and Decoding Functions 


The encoding and decoding functions let you inspect and decode data in the database. The encoding and decoding 
functions are: 


DECODE 

DUMP 

ORA_HASH 
STANDARD_HASH 
VSIZE 


NULL-Related Functions 
The NULL-related functions facilitate null handling. The NULL-related functions are: 


COALESCE 
LNNVL 
NANVL 

« NULLIF 

e NVL 

e NVL2 


Environment and Identifier Functions 


The environment and identifier functions provide information about the instance and session. The environment and 
identifier functions are: 


«+ CON_DBID_TO_ID 

«+ CON_GUID_TO_ID 

- CON_NAME_TO_ID 
CON_UID_TO_ID 
ORA_INVOKING_USER 
ORA_INVOKING_USERID 
SYS_CONTEXT 


SYS_GUID 
SYS_TYPEID 
- UID 
- USER 
e USERENV 


Aggregate Functions 


Aggregate functions return a single result row based on groups of rows, rather than on single rows. Aggregate 
functions can appear in select lists and in ORDER BY and HAVING clauses. They are commonly used with 

the GROUP BY clause in a SELECT statement, where Oracle Database divides the rows of a queried table or view 
into groups. In a query containing a GROUP BY clause, the elements of the select list can be aggregate 


functions, GROUP BY expressions, constants, or expressions involving one of these. Oracle applies the aggregate 
functions to each group of rows and returns a single result row for each group. 


If you omit the GROUP BY clause, then Oracle applies aggregate functions in the select list to all the rows in the 
queried table or view. You use aggregate functions in the HAVING clause to eliminate groups from the output 
based on the results of the aggregate functions, rather than on the values of the individual rows of the queried table 
or view. 


Many (but not all) aggregate functions that take a single argument accept these clauses: 


DISTINCT and UNIQUE, which are synonymous, cause an aggregate function to consider only distinct 
values of the argument expression. The syntax diagrams for aggregate functions in this chapter use the 
keyword DISTINCT for simplicity. 


ALL causes an aggregate function to consider all values, including all duplicates. 


For example, the DISTINCT average of 1, 1, 1, and 3 is 2. The ALL average is 1.5. If you specify neither, then the 
default is ALL. 


All aggregate functions except COUNT(*), GROUPING, and GROUPING_ID ignore nulls. You can use 

the NVL function in the argument to an aggregate function to substitute a value for a 

null. COUNT and REGR_COUNT never return null, but return either a number or zero. For all the remaining 
aggregate functions, if the data set contains no rows, or contains only rows with nulls as arguments to the 
aggregate function, then the function returns null. 


The aggregate functions MIN, MAX, SUM, AVG, COUNT, VARIANCE, and STDDEV, when followed by 
the KEEP keyword, can be used in conjunction with the FIRST or LAST function to operate on a set of values 
from a set of rows that rank as the FIRST or LAST with respect to a given sorting specification. 


You can nest aggregate functions. For example, the following example calculates the average of the maximum 
salaries of all the departments in the sample schema hr: 


SELECT AVG(MA X(salary)) 
FROM employees 
GROUP BY department_id; 


AVG(MAX(SALARY)) 


10926.3333 


This calculation evaluates the inner aggregate (MAX(salary)) for each group defined by the GROUP BY clause 
(department_id), and aggregates the results again. 


In the list of aggregate functions that follows, functions followed by an asterisk (*) allow the windowing_clause . 


APPROX_COUNT 
APPROX_COUNT_DISTINCT 
APPROX_COUNT_DISTINCT_AGG 
APPROX_COUNT_DISTINCT_DETAIL 
APPROX_MEDIAN 
APPROX_PERCENTILE 

+ APPROX_PERCENTILE_AGG 

- APPROX_PERCENTILE_DETAIL 

+ APPROX_RANK 

- APPROX_SUM 

- AVG 

e COLLECT 
CORR 
CORR_* 


COUNT 
COVAR_POP 
COVAR_SAMP 
CUME_DIST 
DENSE_RANK 

- FIRST 

e GROUP_ID 

e GROUPING 

- GROUPING_ID 

e JSON_ARRAYAGG 
JSON_OBJECTAGG 
LAST 
LISTAGG 
MAX 
MEDIAN 
MIN 
PERCENT_RANK 

e PERCENTILE_CONT 

e PERCENTILE_DISC 

- RANK 

e REGR_ (Linear Regression) Functions 

e STATS_BINOMIAL_TEST 

e STATS_CROSSTAB 
STATS_F_TEST 
STATS_KS_TEST 
STATS_MODE 
STATS_MW_TEST 
STATS_ONE_WAY_ANOVA 
STATS_T_TEST_* 

e STATS_WSR_TEST 

- STDDEV 

- STDDEV_POP 

e STDDEV_SAMP 

- SUM 
SYS_OP_ZONE_ID 
SYS_XMLAGG 
TO_APPROX_COUNT_DISTINCT 
TO_APPROX_PERCENTILE 
VAR_POP 
VAR_SAMP 
VARIANCE 
XMLAGG 


Analytic Functions 


Analytic functions compute an aggregate value based on a group of rows. They differ from aggregate functions in 
that they return multiple rows for each group. The group of rows is called a window and is defined by the 
analytic_clause . For each row, a sliding window of rows is defined. The window determines the range of rows 
used to perform the calculations for the current row. Window sizes can be based on either a physical number of 
rows or a logical interval such as time. 


Analytic functions are the last set of operations performed in a query except for the final ORDER BY clause. All 
joins and all WHERE, GROUP BY, and HAVING clauses are completed before the analytic functions are 
processed. Therefore, analytic functions can appear only in the select list or ORDER BY clause. 


Analytic functions are commonly used to compute cumulative, moving, centered, and reporting aggregates. 


The semantics of this syntax are discussed in the sections that follow. 
analytic_function 


Specify the name of an analytic function (see the listing of analytic functions following this discussion of 
semantics). 


arguments 


Analytic functions take 0 to 3 arguments. The arguments can be any numeric data type or any nonnumeric data 
type that can be implicitly converted to a numeric data type. Oracle determines the argument with the highest 
numeric precedence and implicitly converts the remaining arguments to that data type. The return type is also that 
data type, unless otherwise noted for an individual function. 


analytic_clause 


Use OVER analytic_clause to indicate that the function operates on a query result set. This clause is computed 
after the FROM, WHERE, GROUP BY, and HAVING clauses. You can specify analytic functions with this clause 
in the select list or ORDER BY clause. To filter the results of a query based on an analytic function, nest these 
functions within the parent query, and then filter the results of the nested subquery. 


Notes on the analytic_clause : 
The following notes apply to the analytic_clause : 

- You cannot nest analytic functions by specifying any analytic function in any part of the analytic_clause . 
However, you can specify an analytic function in a subquery and compute another analytic function over 
it. 

e You can specify OVER analytic_clause with user-defined analytic functions as well as built-in analytic 
functions. 

- The PARTITION BY and ORDER BY clauses in the analytic_clause are collation-sensitive. 

query_partition_clause 
Use the PARTITION BY clause to partition the query result set into groups based on one or more value_expr . If 
you omit this clause, then the function treats all rows of the query result set as a single group. 


To use the query_partition_clause in an analytic function, use the upper branch of the syntax (without 
parentheses). To use this clause in a model query (in the model_column_clauses ) or a partitioned outer join (in 
the outer_join_clause ), use the lower branch of the syntax (with parentheses). 


You can specify multiple analytic functions in the same query, each with the same or 
different PARTITION BY keys. 


If the objects being queried have the parallel attribute, and if you specify an analytic function with the 
query_partition_clause , then the function computations are parallelized as well. 


Valid values of value_expr are constants, columns, nonanalytic functions, function expressions, or expressions 
involving any of these. 


order_by_clause 


Use the order_by_clause to specify how data is ordered within a partition. For all analytic functions you can 
order the values in a partition on multiple keys, each defined by a value_expr and each qualified by an ordering 
sequence. 


Within each function, you can specify multiple ordering expressions. Doing so is especially useful when using 
functions that rank values, because the second expression can resolve ties between identical values for the first 
expression. 


Whenever the order_by_clause results in identical values for multiple rows, the function behaves as follows: 


- CUME_DIST, DENSE_RANK, NTILE, PERCENT_RANK, and RANK return the same result for each of 
the rows. 


ROW_NUMBER assigns each row a distinct value even if there is a tie based on the order_by_clause . 
The value is based on the order in which the row is processed, which may be nondeterministic if 
the ORDER BY does not guarantee a total ordering. 


e For all other analytic functions, the result depends on the window specification. If you specify a logical 
window with the RANGE keyword, then the function returns the same result for each of the rows. If you 
specify a physical window with the ROWS keyword, then the result is nondeterministic. 


Restrictions on the ORDER BY Clause 
The following restrictions apply to the ORDER BY clause: 


When used in an analytic function, the order_by_clause must take an expression (expr ). 

The SIBLINGS keyword is not valid (it is relevant only in hierarchical queries). Position ( position ) and 
column aliases (c_alias ) are also invalid. Otherwise this order_by_clause is the same as that used to 
order the overall query or subquery. 


An analytic function that uses the RANGE keyword can use multiple sort keys in its ORDER BY clause if 
it specifies any of the following windows: 
o RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. The short form of 
this is RANGE UNBOUNDED PRECEDING. 


o RANGE BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING 
o RANGE BETWEEN CURRENT ROW AND CURRENT ROW 
o RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING 


Window boundaries other than these four can have only one sort key in the ORDER BY clause of the 
analytic function. This restriction does not apply to window boundaries specified by the ROW keyword. 


ASC | DESC 

Specify the ordering sequence (ascending or descending). ASC is the default. 

NULLS FIRST | NULLS LAST 

Specify whether returned rows containing nulls should appear first or last in the ordering sequence. 
NULLS LAST is the default for ascending order, and NULLS FIRST is the default for descending order. 


Analytic functions always operate on rows in the order specified in the order_by_clause of the function. 
However, the order_by_clause of the function does not guarantee the order of the result. Use the 
order_by_clause of the query to guarantee the final result ordering. 


windowing_clause 


Some analytic functions allow the windowing_clause . In the listing of analytic functions at the end of this section, 
the functions that allow the windowing_clause are followed by an asterisk (*). 


ROWS | RANGE 


These keywords define for each row a window (a physical or logical set of rows) used for calculating the function 
result. The function is then applied to all the rows in the window. The window moves through the query result set 
or partition from top to bottom. 


ROWS specifies the window in physical units (rows). 


- RANGE specifies the window as a logical offset. 


You cannot specify this clause unless you have specified the order_by_clause . Some window boundaries defined 
by the RANGE clause let you specify only one expression in the order_by_clause . 


The value returned by an analytic function with a logical offset is always deterministic. However, the value 
returned by an analytic function with a physical offset may produce nondeterministic results unless the ordering 
expression results in a unique ordering. You may have to specify multiple columns in the order_by_clause to 
achieve this unique ordering. 


BETWEEN ... AND 


Use the BETWEEN ... AND clause to specify a start point and end point for the window. The first expression 
(before AND) defines the start point and the second expression (after AND) defines the end point. 


If you omit BETWEEN and specify only one end point, then Oracle considers it the start point, and the end point 
defaults to the current row. 
UNBOUNDED PRECEDING 


Specify UNBOUNDED PRECEDING to indicate that the window starts at the first row of the partition. This is the 
start point specification and cannot be used as an end point specification. 


UNBOUNDED FOLLOWING 


Specify UNBOUNDED FOLLOWING to indicate that the window ends at the last row of the partition. This is the 
end point specification and cannot be used as a start point specification. 


CURRENT ROW 


As a Start point, CURRENT ROW specifies that the window begins at the current row or value (depending on 
whether you have specified ROW or RANGE, respectively). In this case the end point cannot be value_expr 
PRECEDING. 


As an end point, CURRENT ROW specifies that the window ends at the current row or value (depending on 
whether you have specified ROW or RANGE, respectively). In this case the start point cannot be value_expr 
FOLLOWING. 


value_expr PRECEDING or value_expr FOLLOWING 
For RANGE or ROW: 


If value_expr FOLLOWING is the start point, then the end point must be value_expr FOLLOWING. 
If value_expr PRECEDING is the end point, then the start point must be value_expr PRECEDING. 


If you are defining a logical window defined by an interval of time in numeric format, then you may need to use 
conversion functions. 


If you specified ROWS: 


value_expr is a physical offset. It must be a constant or expression and must evaluate to a positive 
numeric value. 


If value_expr is part of the start point, then it must evaluate to a row before the end point. 
If you specified RANGE: 
e value_expr is a logical offset. It must be a constant or expression that evaluates to a positive numeric 
value or an interval literal. 
You can specify only one expression in the order_by_clause . 


If value_expr evaluates to a numeric value, then the ORDER BY expr must be a numeric or DATE data 
type. 
If value_expr evaluates to an interval value, then the ORDER BY expr must be a DATE data type. 


If you omit the windowing_clause entirely, then the default 
is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. 


Analytic functions are commonly used in data warehousing environments. In the list of analytic functions that 
follows, functions followed by an asterisk (*) allow the full syntax, including the windowing_clause . 


- AVG* 
e CLUSTER_DETAILS 
e CLUSTER_DISTANCE 


CLUSTER_ID 
CLUSTER_PROBABILITY 
CLUSTER_SET 
CORR * 
COUNT * 

«+ COVAR_POP * 

e COVAR_SAMP * 

«e CUME_DIST 

- DENSE_RANK 

e FEATURE_DETAILS 
FEATURE_ID 
FEATURE_SET 
FEATURE_VALUE 
FIRST 
FIRST_VALUE * 
LAG 
LAST 

+ LAST_VALUE * 

- LEAD 

e LISTAGG 

«e MAX* 

- MIN* 
NTH_VALUE * 
NTILE 
PERCENT_RANK 
PERCENTILE_CONT 
PERCENTILE_DISC 
PREDICTION 
PREDICTION_COST 

+ PREDICTION_DETAILS 

e PREDICTION_PROBABILITY 

e PREDICTION_SET 

- RANK 

e RATIO_TO_REPORT 
REGR_ (Linear Regression) Functions * 
ROW_NUMBER 
STDDEV * 
STDDEV_POP * 
STDDEV_SAMP * 
SUM * 
VAR_POP * 

+ VAR_SAMP * 

- VARIANCE * 


Object Reference Functions 


Object reference functions manipulate REF values, which are references to objects of specified object types. The 
object reference functions are: 


« DEREF 

- MAKE REF 
- REF 

e REFTOHEX 
- VALUE 


Model Functions 


Model functions can be used only in the model_clause of the SELECT statement. The model functions are: 


CV 
ITERATION_NUMBER 
PRESENTNNV 
PRESENTV 
PREVIOUS 


OLAP Functions 


OLAP functions returns data from a dimensional object in two-dimension relational format. The OLAP function 
is: 


CUBE_TABLE 


Data Cartridge Functions 


Data Cartridge functions are useful for Data Cartridge developers. The Data Cartridge functions are: 


+ DATAOBJ_TO_MAT_PARTITION 
- DATAOBJ_TO_PARTITION 


Common SQL DDL Clauses 
This chapter describes some SQL data definition clauses that appear in multiple SQL statements. 
This chapter contains these sections: 


allocate_extent_clause 

e constraint 
deallocate_unused_clause 
file_specification 

- logging_clause 
parallel_clause 
physical_attributes_clause 
size_clause 
storage_clause 


allocate_extent_clause 
Use the allocate_extent_clause clause to explicitly allocate a new extent for a database object. 


Explicitly allocating an extent with this clause does not change the values of 
the NEXT and PCTINCREASE storage parameters, so does not affect the size of the next extent to be allocated 
implicitly by Oracle Database. 


SIZE 


Specify the size of the extent in bytes. The value of integer can be 0 through 2147483647. To specify a larger 
extent size, use an integer within this range with K, M, G, or T to specify the extent size in kilobytes, megabytes, 
gigabytes, or terabytes. 


For a table, index, materialized view, or materialized view log, if you omit SIZE, then Oracle Database determines 
the size based on the values of the storage parameters of the object. However, for a cluster, Oracle does not 
evaluate the cluster's storage parameters, so you must specify SIZE if you do not want Oracle to use a default 
value. 


DATAFILE ' filename ' 


Specify one of the data files in the tablespace of the table, cluster, index, materialized view, or materialized view 
log to contain the new extent. If you omit DATAFILE, then Oracle chooses the data file. 


INSTANCE integer 
Use this parameter only if you are using Oracle Real Application Clusters. 


Specifying INSTANCE integer makes the new extent available to the freelist group associated with the specified 
instance. If the instance number exceeds the maximum number of freelist groups, then Oracle divides the specified 
number by the maximum number and uses the remainder to identify the freelist group to be used. An instance is 
identified by the value of its initialization parameter INSTANCE_NUMBER. 


If you omit this parameter, then the space is allocated to the table, cluster, index, materialized view, or materialized 
view log but is not drawn from any particular freelist group. Instead, Oracle uses the master freelist and allocates 
space as needed. 


constraint 


Use a constraint to define an integrity constraint— a rule that restricts the values in a database. Oracle 
Database lets you create six types of constraints and lets you declare them in two ways. 


The six types of integrity constraint are described briefly here: 


+ A NOT NULL constraint prohibits a database value from being null. 


- A unique constraint prohibits multiple rows from having the same value in the same column or 
combination of columns but allows some values to be null. 


- A primary key constraint combines a NOT NULL constraint and a unique constraint in a single 
declaration. It prohibits multiple rows from having the same value in the same column or combination of 
columns and prohibits values from being null. 


- A foreign key constraint requires values in one table to match values in another table. 
- A check constraint requires a value in the database to comply with a specified condition. 


- AREF column by definition references an object in another object type or in a relational table. A REF 
constraint lets you further describe the relationship between the REF column and the object it references. 


You can define constraints syntactically in two ways: 


- As part of the definition of an individual column or attribute. This is called inline specification. 


- As part of the table definition. This is called out-of-line specification. 
NOT NULL constraints must be declared inline. All other constraints can be declared either inline or out of line. 
Constraint clauses can appear in the following statements: 


- CREATE TABLE 
- ALTER TABLE 

© CREATE VIEW 
© ALTER VIEW 


View Constraints 


Oracle Database does not enforce view constraints. However, you can enforce constraints on views through 
constraints on base tables. 


You can specify only unique, primary key, and foreign key constraints on views, and they are supported only 
in DISABLE NOVALIDATE mode. You cannot define view constraints on attributes of an object column. 


External Table Constraints 


You can specify only NOT NULL, unique, primary key, and foreign key constraints on external tables. Unique, 
primary key, and foreign key constraints are supported only in RELY DISABLE mode. 


NOT NULL Constraints 


A NOT NULL constraint prohibits a column from containing nulls. The NULL keyword by itself does not actually 
define an integrity constraint, but you can specify it to explicitly permit a column to contain nulls. You must 
define NOT NULL and NULL using inline specification. If you specify neither NOT NULL nor NULL, then the 
default is NULL. 


NOT NULL constraints are the only constraints you can specify inline on XMLType and VARRAY columns. 
To satisfy a NOT NULL constraint, every row in the table must contain a value for the column. 
Unique Constraints 


A unique constraint designates a column as a unique key. A composite unique key designates a combination of 
columns as the unique key. When you define a unique constraint inline, you need only the UNIQUE keyword. 
When you define a unique constraint out of line, you must also specify one or more columns. You must define a 
composite unique key out of line. 


To satisfy a unique constraint, no two rows in the table can have the same value for the unique key. However, the 
unique key made up of a single column can contain nulls. To satisfy a composite unique key, no two rows in the 
table or view can have the same combination of values in the key columns. Any row that contains nulls in all key 
columns automatically satisfies the constraint. However, two rows that contain nulls for one or more key columns 
and the same combination of values for the other key columns violate the constraint. 


When you specify a unique constraint on one or more columns, Oracle implicitly creates an index on the unique 
key. If you are defining uniqueness for purposes of query performance, then Oracle recommends that you instead 
create the unique index explicitly using a CREATE UNIQUE INDEX statement. You can also use 

the CREATE UNIQUE INDEX statement to create a unique function-based index that defines a conditional unique 
constraint. 


When you specify an enabled unique constraint on an extended data type column, you may receive a "Maximum 
key length exceeded" error when Oracle tries to create the index to enforce uniqueness for the enabled constraint. 


Primary Key Constraints 


A primary key constraint designates a column as the primary key of a table or view. A composite primary key 
designates a combination of columns as the primary key. When you define a primary key constraint inline, you 
need only the PRIMARY KEY keywords. When you define a primary key constraint out of line, you must also 
specify one or more columns. You must define a composite primary key out of line. 


To satisfy a primary key constraint: 
- No primary key value can appear in more than one row in the table. 
«e No column that is part of the primary key can contain a null. 

When you create a primary key constraint: 


e Oracle Database uses an existing index if it contains a unique set of values before enforcing the primary 
key constraint. The existing index can be defined as unique or nonunique. When a DML operation is 
performed, the primary key constraint is enforced using this existing index. 


- If no existing index can be used, then Oracle Database generates a unique index. 
When you drop a primary key constraint: 


- Ifthe primary key was created using an existing index, then the index is not dropped. 


- Ifthe primary key was created using a system-generated index, then the index is dropped. 


When you designate an extended data type column as an enabled primary key, you may receive a "maximum key 
length exceeded" error when Oracle tries to create the index to enforce uniqueness for the enabled constraint. 


Primary key constraints are sensitive to declared collations of their key columns. 
Foreign Key Constraints 


A foreign key constraint (also called a referential integrity constraint ) designates a column as the foreign key 
and establishes a relationship between that foreign key and a specified primary or unique key, called the 
referenced key . A composite foreign key designates a combination of columns as the foreign key. 


The table or view containing the foreign key is called the child object, and the table or view containing the 
referenced key is called the parent object. The foreign key and the referenced key can be in the same table or 
view. In this case, the parent and child tables are the same. If you identify only the parent table or view and omit 
the column name, then the foreign key automatically references the primary key of the parent table or view. The 
corresponding column or columns of the foreign key and the referenced key must match in order, data types, and 
declared collations. 


You can define a foreign key constraint on a single key column either inline or out of line. You must specify a 
composite foreign key and a foreign key on an attribute out of line. 


To satisfy a composite foreign key constraint, the composite foreign key must refer to a composite unique key or a 
composite primary key in the parent table or view, or the value of at least one of the columns of the foreign key 
must be null. 


You can designate the same column or combination of columns as both a foreign key and a primary or unique key. 
You can also designate the same column or combination of columns as both a foreign key and a cluster key. 


You can define multiple foreign keys in a table or view. Also, a single column can be part of more than one foreign 
key. 


references_clause 


Foreign key constraints use the references_clause syntax. When you specify a foreign key constraint inline, you 
need only the references_clause . When you specify a foreign key constraint out of line, you must also specify 
the FOREIGN KEY keywords and one or more columns. 


ON DELETE Clause 


The ON DELETE clause lets you determine how Oracle Database automatically maintains referential integrity if 
you remove a referenced primary or unique key value. If you omit this clause, then Oracle does not allow you to 
delete referenced key values in the parent table that have dependent rows in the child table. 


+ Specify CASCADE if you want Oracle to remove dependent foreign key values. 


- Specify SET NULL if you want Oracle to convert dependent foreign key values to NULL. You cannot 
specify this clause for a virtual column, because the values in a virtual column cannot be updated directly. 
Rather, the values from which the virtual column are derived must be updated. 


Check Constraints 


A check constraint lets you specify a condition that each row in the table must satisfy. To satisfy the constraint, 
each row in the table must make the condition either TRUE or unknown (due to a null). When Oracle evaluates a 
check constraint condition for a particular row, any column names in the condition refer to the column values in 
that row. 


The syntax for inline and out-of-line specification of check constraints is the same. However, inline specification 
can refer only to the column (or the attributes of the column if it is an object column) currently being defined, 
whereas out-of-line specification can refer to multiple columns or attributes. 


Oracle does not verify that conditions of check constraints are not mutually exclusive. Therefore, if you create 
multiple check constraints for a column, design them carefully so their purposes do not conflict. Do not assume 
any particular order of evaluation of the conditions. 


If the condition of a check constraint depends on NLS parameters, such as NLS_DATE_FORMAT, Oracle 
evaluates the condition using the database values of the parameters, not the session values. You can find the 
database values of the NLS parameters in the data dictionary view NLS_DATABASE_PARAMETERS. These 
values are associated with a database by the DDL statement CREATE DATABASE and never change afterwards. 


REF Constraints 


REF constraints let you describe the relationship between a column of type REF and the object it references. 
ref_constraint 


REF constraints use the ref_constraint syntax. You define a REF constraint either inline or out of line. Out-of-line 
specification requires you to specify the REF column or attribute you are further describing. 


For ref_column, specify the name of a REF column of an object or relational table. 


For ref_attribute , specify an embedded REF attribute within an object column of a relational table. 


Both inline and out-of-line specification let you define a scope constraint, a rowid constraint, or a referential 
integrity constraint on a REF column. 


If the scope table or referenced table of the REF column has a primary-key-based object identifier, then 
the REF column is a user-defined REF column . 


SCOPE REF Constraints 


In a table with a REF column, each REF value in the column can conceivably reference a row in a different object 
table. The SCOPE clause restricts the scope of references to a single table, scope_table . The values in 

the REF column or attribute point to objects in scope_table , in which object instances of the same type as 

the REF column are stored. 


Specify the SCOPE clause to restrict the scope of references in the REF column to a single table. For you to 
specify this clause, scope_table must be in your own schema, or you must have the READ or SELECT privilege 
on scope_table , or you must have the READ ANY TABLE or SELECT ANY TABLE system privilege. You can 
specify only one scope table for each REF column. 


Rowid REF Constraints 


Specify WITH ROWID to store the rowid along with the REF value in ref_column or ref_attribute . Storing the 
rowid with the REF value can improve the performance of dereferencing operations, but will also use more space. 
Default storage of REF values is without rowids. 


Referential Integrity Constraints on REF Columns 


The references_clause of the ref_constraint syntax lets you define a foreign key constraint on the REF column. 
This clause also implicitly restricts the scope of the REF column or attribute to the referenced table. However, 
whereas a foreign key constraint on a non-REF column references an actual column in the parent table, a foreign 
key constraint on a REF column references the implicit object identifier column of the parent table. 


If you do not specify a constraint name, then Oracle generates a system name for the constraint of the form SYS_C 
n. 


If you add a referential integrity constraint to an existing REF column that is already scoped, then the referenced 
table must be the same as the scope table of the REF column. If you later drop the referential integrity constraint, 
then the REF column will remain scoped to the referenced table. 


As is the case for foreign key constraints on other types of columns, you can use the references_clause alone for 
inline declaration. For out-of-line declaration you must also specify the FOREIGN KEY keywords plus one or 
more REF columns or attributes. 


Collation Sensitivity of Constraints 


Starting with Oracle Database 12 c Release 2 (12.2), primary key, unique, and foreign key constraints are sensitive 
to declared collations of their key columns. A primary or unique key character column value from a new or 
updated row is compared with values in existing rows using the declared collation of the key column. For example, 
if the declared collation of the key column is the case-insensitive collation BINARY_CI, a new or updated row 
may be rejected if the new key column value differs from some existing key value only by case. The 

collation BINARY_CTI treats character values differing only by case as equal. 


A foreign key character column value is compared to parent primary or unique key column values using the 
declared collation of the parent key column. For example, if the declared collation of the key column is the case- 
insensitive collation BINARY_CI, a new or updated child row may be accepted even if there is no identical parent 
key value for the corresponding foreign key value, provided there exists a value differing only by case. 


The declared collation of a foreign key column must be the same as the collation of the corresponding parent key 
column. 


Columns in a composite key of a constraint may have different declared collations. 


When the declared collation of a key column of a constraint is a pseudo-collation, the constraint uses a 
corresponding variant of the collation BINARY. Pseudo-collations cannot be used directly to compare values for a 
constraint, because constraints are static and cannot depend on session NLS parameters on which the pseudo- 
collations depend. Therefore: 


The pseudo-collations USING_NLS_COMP, USING_NLS_SORT, and USING_NLS_SORT_CS use the 
collation BINARY. 


- The pseudo-collation USING_NLS_COMP_CI uses the collation BINARY_CI. 
The pseudo-collation USING_NLS_COMP_AI uses the collation BINARY_AI. 


When the effective collation used by a primary or unique key column is not BINARY, Oracle creates a hidden 
virtual column for this column. The expression of the virtual column calculates collation keys for character values 
of the original key column. The primary key or unique constraint is internally created on the virtual column instead 
of the original column. The virtual column is visible in the data dictionary views of the *_TAB_COLS family. For 
each of these hidden virtual columns, the COLLATED _COLUMN_ID of the *_TAB COLS views contains the 
internal sequence number pointing to the corresponding original key column. The hidden virtual columns count to 
the 1000-column limit of a table. 


Specifying Constraint State 


You can specify how and when Oracle should enforce the constraint when you define the constraint. 


constraint_state 


You can use constraint_state with both inline and out-of-line specification. Except for the 
clauses DEFERRABLE and INITIALLY, that may be specified in any order, you must specify the rest of the 
component clauses in the order shown, and each clause only once. 


DEFERRABLE Clause 


The DEFERRABLE and NOT DEFERRABLE parameters indicate whether or not, in subsequent transactions, 
constraint checking can be deferred until the end of the transaction using the SET CONSTRAINT(S) statement. If 
you omit this clause, then the default is NOT DEFERRABLE. 


Specify NOT DEFERRABLE to indicate that in subsequent transactions you cannot use 
the SET CONSTRAINT[S] clause to defer checking of this constraint until the transaction is committed. 
The checking of a NOT DEFERRABLE constraint can never be deferred to the end of the transaction. 


If you declare a new constraint NOT DEFERRABLE, then it must be valid at the time 
the CREATE TABLE or ALTER TABLE statement is committed or the statement will fail. 


Specify DEFERRABLE to indicate that in subsequent transactions you can use 
the SET CONSTRAINT[S] clause to defer checking of this constraint until a COMMIT statement is 
submitted. If the constraint check fails, then the database returns an error and the transaction is not 


committed. This setting in effect lets you disable the constraint temporarily while making changes to the 
database that might violate the constraint until all the changes are complete. 


You cannot alter the deferrability of a constraint. Whether you specify either of these parameters, or make the 
constraint NOT DEFERRABLE implicitly by specifying neither of them, you cannot specify this clause in 
an ALTER TABLE statement. You must drop the constraint and re-create it. 


Restriction on [NOT] DEFERRABLE 


You cannot specify either of these parameters for a view constraint. 


INITIALLY Clause 


The INITIALLY clause establishes the default checking behavior for constraints that are DEFERRABLE. 
The INITIALLY setting can be overridden by a SET CONSTRAINT(S) statement in a subsequent transaction. 


e Specify INITIALLY IMMEDIATE to indicate that Oracle should check this constraint at the end of each 
subsequent SQL statement. If you do not specify INITIALLY at all, then the default 
is INITIALLY IMMEDIATE. 


If you declare a new constraint INITIALLY IMMEDIATE, then it must be valid at the time 
the CREATE TABLE or ALTER TABLE statement is committed or the statement will fail. 


- Specify INITIALLY DEFERRED to indicate that Oracle should check this constraint at the end of 
subsequent transactions. 


This clause is not valid if you have declared the constraint to be NOT DEFERRABLE, because 
a NOT DEFERRABLE constraint is automatically INITIALLY IMMEDIATE and cannot ever 
be INITIALLY DEFERRED. 


RELY Clause 


The RELY and NORELY parameters specify whether a constraint in NOVALIDATE mode is to be taken into 
account for query rewrite. Specify RELY to activate a constraint in NOVALIDATE mode for query rewrite in an 
unenforced query rewrite integrity mode. The constraint is in NOVALIDATE mode, so Oracle does not enforce it. 
The default is NORELY. 


Unenforced constraints are generally useful only with materialized views and query rewrite. Depending on 
the QUERY_REWRITE_INTEGRITY mode, query rewrite can use only constraints that are in VALIDATE mode, 
or that are in NOVALIDATE mode with the RELY parameter set, to determine join information. 


Using Indexes to Enforce Constraints 

When defining the state of a unique or primary key constraint, you can specify an index for Oracle to use to 
enforce the constraint, or you can instruct Oracle to create the index used to enforce the constraint. 
using_index_clause 


You can specify the using_index_clause only when enabling unique or primary key constraints. You can specify 
the clauses of the using_index_clause in any order, but you can specify each clause only once. 


- Ifyou specify schema.index , then Oracle attempts to enforce the constraint using the specified index. If 
Oracle cannot find the index or cannot use the index to enforce the constraint, then Oracle returns an error. 


If you specify the create_index_statement , then Oracle attempts to create the index and use it to enforce 
the constraint. If Oracle cannot create the index or cannot use the index to enforce the constraint, then 
Oracle returns an error. 


- Ifyou neither specify an existing index nor create a new index, then Oracle creates the index. In this case: 
o The index receives the same name as the constraint. 


o If table is partitioned, then you can specify a locally or globally partitioned index for the unique 
or primary key constraint. 


ENABLE Clause 


Specify ENABLE if you want the constraint to be applied to the data in the table. 


If you enable a unique or primary key constraint, and if no index exists on the key, then Oracle Database creates a 
unique index. Unless you specify KEEP INDEX when subsequently disabling the constraint, this index is dropped 
and the database rebuilds the index every time the constraint is reenabled. 


You can also avoid rebuilding the index and eliminate redundant indexes by creating new primary key and unique 
constraints initially disabled. Then create (or use existing) nonunique indexes to enforce the constraint. Oracle 
does not drop a nonunique index when the constraint is disabled, so subsequent ENABLE operations are 
facilitated. 


ENABLE VALIDATE specifies that all old and new data also complies with the constraint. An enabled 
validated constraint guarantees that all data is and will continue to be valid. 


If any row in the table violates the integrity constraint, then the constraint remains disabled and Oracle 
returns an error. If all rows comply with the constraint, then Oracle enables the constraint. Subsequently, 
if new data violates the constraint, then Oracle does not execute the statement and returns an error 
indicating the integrity constraint violation. 


If you place a primary key constraint in ENABLE VALIDATE mode, then the validation process will 
verify that the primary key columns contain no nulls. To avoid this overhead, mark each column in the 
primary key NOT NULL before entering data into the column and before enabling the primary key 
constraint of the table. 


- ENABLE NOVALIDATE ensures that all new DML operations on the constrained data comply with the 
constraint. This clause does not ensure that existing data in the table complies with the constraint. 


If you specify neither VALIDATE nor NOVALIDATE, then the default is VALIDATE. 


If you change the state of any single constraint from ENABLE NOVALIDATE to ENABLE VALIDATE, then the 
operation can be performed in parallel, and does not block reads, writes, or other DDL operations. 


DISABLE Clause 


Specify DISABLE to disable the integrity constraint. Disabled integrity constraints appear in the data dictionary 
along with enabled constraints. If you do not specify this clause when creating a constraint, then Oracle 
automatically enables the constraint. 


DISABLE VALIDATE disables the constraint and drops the index on the constraint, but keeps the 
constraint valid. This feature is most useful in data warehousing situations, because it lets you load large 
amounts of data while also saving space by not having an index. This setting lets you load data from a 
nonpartitioned table into a partitioned table using the exchange_partition_subpart clause of 

the ALTER TABLE statement or using SQL*Loader. All other modifications to the table (inserts, updates, 
and deletes) by other SQL statements are disallowed. 


DISABLE NOVALIDATE signifies that Oracle makes no effort to maintain the constraint (because it is 
disabled) and cannot guarantee that the constraint is true (because it is not being validated). 


You cannot drop a table whose primary key is being referenced by a foreign key even if the foreign key 
constraint is in DISABLE NOVALIDATE state. Further, the optimizer can use constraints 
in DISABLE NOVALIDATE state. 


If you specify neither VALIDATE nor NOVALIDATE, then the default is NOVALIDATE. 


If you disable a unique or primary key constraint that is using a unique index, then Oracle drops the unique index. 


VALIDATE | NOVALIDATE 


The behavior of VALIDATE and NOVALIDATE depends on whether the constraint is enabled or disabled, either 
explicitly or by default. 


Note on Foreign Key Constraints in NOVALIDATE Mode 


When a foreign key constraint is in NOVALIDATE mode, if existing data in the table does not comply with the 
constraint and the QUERY_REWRITE_INTEGRITY parameter is not set to ENFORCED, then the optimizer may 
use join elimination during queries on the table. In this case, a query may return table rows with noncompliant 
foreign key values even if the query contains a join condition that should filter out those rows. 


Handling Constraint Exceptions 


When defining the state of a constraint, you can specify a table into which Oracle places the rowids of all rows 
violating the constraint. 


exceptions_clause 


Use the exceptions_clause syntax to define exception handling. If you omit schema , then Oracle assumes the 
exceptions table is in your own schema. If you omit this clause altogether, then Oracle assumes that the table is 
named EXCEPTIONS. The EXCEPTIONS table or the table you specify must exist on your local database. 


You can create the EXCEPTIONS table using one of these scripts: 


UTLEXCPT.SQL uses physical rowids. Therefore it can accommodate rows from conventional tables but 
not from index-organized tables. (See the Note that follows.) 
e UTLEXPT1.SQL uses universal rowids, so it can accommodate rows from both conventional and index- 
organized tables. 
If you create your own exceptions table, then it must follow the format prescribed by one of these two scripts. 


If you are collecting exceptions from index-organized tables based on primary keys (rather than universal rowids), 
then you must create a separate exceptions table for each index-organized table to accommodate its primary-key 
storage. You create multiple exceptions tables with different names by modifying and resubmitting the script. 


View Constraints 


Oracle does not enforce view constraints. However, operations on views are subject to the integrity constraints 
defined on the underlying base tables. This means that you can enforce constraints on views through constraints on 
base tables. 


Notes on View Constraints 
View constraints are a subset of table constraints and are subject to the following restrictions: 


You can specify only unique, primary key, and foreign key constraints on views. However, you can define 
the view using the WITH CHECK OPTION clause, which is equivalent to specifying a check constraint 
for the view. 


View constraints are supported only in DISABLE NOVALIDATE mode. You cannot specify any other 
mode. You must specify the keyword DISABLE when you declare the view constraint. You need not 
specify NOVALIDATE explicitly, as it is the default. 


The RELY and NORELY parameters are optional. View constraints, because they are unenforced, are 
usually specified with the RELY parameter to make them more useful. The RELY or NORELY keyword 
must precede the DISABLE keyword. 


e Because view constraints are not enforced directly, you cannot 
specify INITIALLY DEFERRED or DEFERRABLE. 


You cannot specify the using_index_clause , the exceptions_clause clause, or the ON DELETE clause of 
the references_clause . 


You cannot define view constraints on attributes of an object column. 


External Table Constraints 


Starting with Oracle Database 12 c Release 2 (12.2), you can specify NOT NULL, unique, primary key, and 
foreign key constraints on external tables. 


NOT NULL constraints on external tables are enforced and prohibit columns from containing nulls. 


Unique, primary key, and foreign key constraints are supported on external tables only in RELY DISABLE mode. 
You must specify the keywords RELY and DISABLE when you create these constraints. These constraints are 
declarative and are not enforced. They can increase query performance and reduce resource consumption because 
more optimizer transformations can be taken into account. In order for the optimizer to utilize 

these RELY DISABLE constraints, the QUERY_REWRITE_INTEGRITY initialization parameter must be set to 
either trusted or stale_tolerated. 


Examples 
Unique Key Example 


The following statement is a variation of the statement that created the sample table sh.promotions. It defines 
inline and implicitly enables a unique key on the promo_id column (other constraints are not shown): 


CREATE TABLE promotions_var1 
( promo_id NUMBER(6) 
CONSTRAINT promo_id_u UNIQUE 
, promo_name VARCHAR2(20) 
, promo_category VARCHAR2(15) 
,promo_cost NUMBER(10,2) 
, promo_begin_date DATE 
, promo_end_date DATE 


); 


The constraint promo_id_u identifies the promo_id column as a unique key. This constraint ensures that no two 
promotions in the table have the same ID. However, the constraint does allow promotions without identifiers. 


Alternatively, you can define and enable this constraint out of line: 


CREATE TABLE promotions_var2 
( promo_id NUMBER(6) 
, promo_name VARCHAR2(20) 
, promo_category VARCHAR2(15) 
,promo_cost NUMBER(10,2) 
, promo_begin_date DATE 
, promo_end_date DATE 
, CONSTRAINT promo_id_u UNIQUE (promo_id) 
USING INDEX PCTFREE 20 
TABLESPACE stocks 
STORAGE (INITIAL 8M) ); 


The preceding statement also contains the using_index_clause , which specifies storage characteristics for the 
index that Oracle creates to enable the constraint. 


Composite Unique Key Example 


The following statement defines and enables a composite unique key on the combination of 
the warehouse_id and warehouse_name columns of the oe.warehouses table: 


ALTER TABLE warehouses 
ADD CONSTRAINT wh_ung UNIQUE (warehouse_id, warehouse_name) 
USING INDEX PCTFREE 5 
EXCEPTIONS INTO wrong_id; 


The wh_ungq constraint ensures that the same combination of warehouse_id and warehouse_name values does not 
appear in the table more than once. 


The ADD CONSTRAINT clause also specifies other properties of the constraint: 


- The USING INDEX clause specifies storage characteristics for the index Oracle creates to enable the 
constraint. 


The EXCEPTIONS INTO clause causes Oracle to write to the wrong_id table information about any rows 
currently in the warehouses table that violate the constraint. If the wrong_id exceptions table does not 
already exist, then this statement will fail. 


Primary Key Example 


The following statement is a variation of the statement that created the sample table hr.locations. It creates 
the locations_demo table and defines and enables a primary key on the location_id column (other constraints from 
the hr.locations table are omitted): 


CREATE TABLE locations_demo 
(location id NUMBER(4) CONSTRAINT loc_id_pk PRIMARY KEY 
, street_address VARCHAR2(40) 
, postal_code VARCHAR2(12) 
, city VARCHAR2(30) 
, state_province VARCHAR2(25) 
, country_id CHAR(2) 
); 


The loc_id_pk constraint, specified inline, identifies the location_id column as the primary key of 
the locations_demo table. This constraint ensures that no two locations in the table have the same location number 
and that no location identifier is NULL. 


Alternatively, you can define and enable this constraint out of line: 


CREATE TABLE locations_demo 
(location id NUMBER(4) 
, street_address VARCHAR2(40) 
, postal_code VARCHAR2(12) 
, city VARCHAR2(30) 
, state_province VARCHAR2(25) 
, country_id CHAR(2) 
, CONSTRAINT loc_id_pk PRIMARY KEY (location_id)); 


NOT NULL Example 


The following statement alters the locations_demo table to define and enable a NOT NULL constraint on 
the country_id column: 


ALTER TABLE locations_ demo 
MODIFY (country_id CONSTRAINT country_nn NOT NULL); 


The constraint country_nn ensures that no location in the table has a null country_id. 
Composite Primary Key Example 


The following statement defines a composite primary key on the combination of the prod_id and cust_id columns 
of the sample table sh.sales: 


ALTER TABLE sales 
ADD CONSTRAINT sales_pk PRIMARY KEY (prod_id, cust_id) DISABLE; 


This constraint identifies the combination of the prod_id and cust_id columns as the primary key of the sales table. 
The constraint ensures that no two rows in the table have the same combination of values for the prod_id column 
and cust_id columns. 


The constraint clause (PRIMARY KEY) also specifies the following properties of the constraint: 


The constraint definition does not include a constraint name, so Oracle generates a name for the constraint. 


- The DISABLE clause causes Oracle to define the constraint but not enable it. 
Foreign Key Constraint Example 


The following statement creates the dept_20 table and defines and enables a foreign key on 
the department_id column that references the primary key on the department_id column of the departments table: 


CREATE TABLE dept_20 
(employee_id NUMBER(4), 
last_name VARCHAR2(10), 
job_id VARCHAR2(9), 
manager_id NUMBER(4), 
hire_date DATE, 
salary NUMBER(7,2), 
commission_pct NUMBER(7,2), 
department_id CONSTRAINT fk_deptno 
REFERENCES departments(department_id) ); 


The constraint fk_deptno ensures that all departments given for employees in the dept_20 table are present in 
the departments table. However, employees can have null department numbers, meaning they are not assigned to 
any department. To ensure that all employees are assigned to a department, you could create 

a NOT NULL constraint on the department_id column in the dept_20 table in addition to 

the REFERENCES constraint. 


Before you define and enable this constraint, you must define and enable a constraint that designates 
the department_id column of the departments table as a primary or unique key. 


The foreign key constraint definition does not use the FOREIGN KEY clause, because the constraint is defined 
inline. The data type of the department_id column is not needed, because Oracle automatically assigns to this 
column the data type of the referenced key. 


The constraint definition identifies both the parent table and the columns of the referenced key. Because the 
referenced key is the primary key of the parent table, the referenced key column names are optional. 


Alternatively, you can define this foreign key constraint out of line: 


CREATE TABLE dept_20 
(employee_id NUMBER(4), 
last_name VARCHAR2(10), 
job_id VARCHAR2(9), 
manager_id NUMBER(4), 
hire_date DATE, 
salary NUMBER(7,2), 
commission_pct NUMBER(7,2), 
department_id, 


CONSTRAINT fk_deptno 
FOREIGN KEY (department_id) 
REFERENCES departments(department_id) ); 


The foreign key definitions in both variations of this statement omit the ON DELETE clause, causing Oracle to 
prevent the deletion of a department if any employee works in that department. 


ON DELETE Example 


This statement creates the dept_20 table, defines and enables two referential integrity constraints, and uses 
the ON DELETE clause: 


CREATE TABLE dept_20 

(employee_id NUMBER(4) PRIMARY KEY, 

last_name VARCHAR2(10), 

job_id VARCHAR2(9), 

manager_id NUMBER(4) CONSTRAINT fk_mgr 
REFERENCES employees ON DELETE SET NULL, 

hire_date DATE, 

salary NUMBER(7,2), 

commission_pct NUMBER(7,2), 

department_id NUMBER(2) CONSTRAINT fk_deptno 
REFERENCES departments(department_id) 
ON DELETE CASCADE ); 


Because of the first ON DELETE clause, if manager number 2332 is deleted from the employees table, then 
Oracle sets to null the value of manager_id for all employees in the dept_20 table who previously had manager 
2332. 


Because of the second ON DELETE clause, Oracle cascades any deletion of a department_id value in 

the departments table to the department_id values of its dependent rows of the dept_20 table. For example, if 
Department 20 is deleted from the departments table, then Oracle deletes all of the employees in Department 20 
from the dept_20 table. 


Composite Foreign Key Constraint Example 


The following statement defines and enables a foreign key on the combination of 
the employee_id and hire_date columns of the dept_20 table: 


ALTER TABLE dept_20 
ADD CONSTRAINT fk_empid_hiredate 
FOREIGN KEY (employee_id, hire_date) 
REFERENCES hr.job_history(employee_id, start_date) 
EXCEPTIONS INTO wrong_emp; 


The constraint fk_empid_hiredate ensures that all the employees in the dept_20 table 

have employee_id and hire_date combinations that exist in the employees table. Before you define and enable this 
constraint, you must define and enable a constraint that designates the combination of 

the employee_id and hire_date columns of the employees table as a primary or unique key. 


The EXCEPTIONS INTO clause causes Oracle to write information to the wrong_emp table about any rows in 
the dept_20 table that violate the constraint. If the wrong_emp exceptions table does not already exist, then this 
statement will fail. 


Check Constraint Examples 


The following statement creates a divisions table and defines a check constraint in each column of the table: 


CREATE TABLE divisions 

(div_no NUMBER CONSTRAINT check_divno 
CHECK (div_no BETWEEN 10 AND 99) 
DISABLE, 

div_name VARCHAR2(9) CONSTRAINT check_divname 
CHECK (div_name = UPPER(div_name)) 
DISABLE, 

office VARCHAR2(10) CONSTRAINT check_office 
CHECK (office IN (DALLAS','BOSTON', 
'PARIS','TOKYO')) 
DISABLE); 


Each constraint restricts the values of the column in which it is defined: 


check_divno ensures that no division numbers are less than 10 or greater than 99. 
check_divname ensures that all division names are in uppercase. 


e check_office restricts office locations to Dallas, Boston, Paris, or Tokyo. 


Because each CONSTRAINT clause contains the DISABLE clause, Oracle only defines the constraints and does 
not enable them. 


The following statement creates the dept_20 table, defining out of line and implicitly enabling a check constraint: 


CREATE TABLE dept_20 
(employee_id NUMBER(4) PRIMARY KEY, 
last_name VARCHAR2(10), 
job_id VARCHAR2(9), 
manager_id NUMBER(4), 
salary NUMBER(7,2), 
commission_pct NUMBER(7,2), 
department_id NUMBER(2), 
CONSTRAINT check_sal CHECK (salary * commission_pct <= 5000)); 


This constraint uses an inequality condition to limit an employee's total commission, the product 
of salary and commission_pct, to $5000: 


If an employee has non-null values for both salary and commission, then the product of these values must 
not exceed $5000 to satisfy the constraint. 


- If an employee has a null salary or commission, then the result of the condition is unknown and the 
employee automatically satisfies the constraint. 


Because the constraint clause in this example does not supply a constraint name, Oracle generates a name for the 
constraint. 


The following statement defines and enables a primary key constraint, two foreign key constraints, 
a NOT NULL constraint, and two check constraints: 


CREATE TABLE order_detail 
(CONSTRAINT pk_od PRIMARY KEY (order_id, part_no), 
order_id NUMBER 
CONSTRAINT fk_oid 
REFERENCES oe.orders(order_id), 


part no NUMBER 

CONSTRAINT fk_pno 
REFERENCES oe.product_information(product_id), 
quantity NUMBER 

CONSTRAINT nn_qty NOT NULL 

CONSTRAINT check_qty CHECK (quantity > 0), 
cost NUMBER 

CONSTRAINT check_cost CHECK (cost > 0) ); 


The constraints enable the following rules on table data: 


- pk_od identifies the combination of the order_id and part_no columns as the primary key of the table. To 
satisfy this constraint, no two rows in the table can contain the same combination of values in 
the order_id and the part_no columns, and no row in the table can have a null in either the order_id or 
the part_no column. 


fk_oid identifies the order_id column as a foreign key that references the order_id column in 
the orders table in the sample schema oe. All new values added to the column order_detail.order_id must 
already appear in the column oe.orders.order_id. 


e fk_pno identifies the product_id column as a foreign key that references the product_id column in 
the product_information table owned by oe. All new values added to the 
column order_detail.product_id must already appear in the column oe.product_information.product_id. 


nn_qty forbids nulls in the quantity column. 
- check_qty ensures that values in the quantity column are always greater than zero. 


check_cost ensures the values in the cost column are always greater than zero. 
This example also illustrates the following points about constraint clauses and column definitions: 


- Out-of-line constraint definition can appear before or after the column definitions. In this example, the 
out-of-line definition of the pk_od constraint precedes the column definitions. 


A column definition can contain multiple inline constraint definitions. In this example, the definition of 
the quantity column contains the definitions of both the nn_qty and check_qty constraints. 


- A table can have multiple CHECK constraints. Multiple CHECK constraints, each with a simple condition 
enforcing a single business rule, are preferable to a single CHECK constraint with a complicated condition 
enforcing multiple business rules. When a constraint is violated, Oracle returns an error identifying the 
constraint. Such an error more precisely identifies the violated business rule if the identified constraint 
enables a single business rule. 


Case-Insensitive Constraints Example 


The following statements create two tables in a parent-child relationship. The parent table is a product description 
table and the child table is a product component description table. Unique constraints are defined to assure that 
product and description values are unambiguous. For illustrative purposes, the product and component ID are case- 
insensitive character values. (In real-world applications, primary key IDs are usually numeric or case-normalized.) 


CREATE TABLE products 
( product_id VARCHAR2(20) COLLATE BINARY_CI 
CONSTRAINT product_pk PRIMARY KEY 
, description VARCHAR2(1000) COLLATE BINARY_CI 
CONSTRAINT product_description_ung UNIQUE 
); 


CREATE TABLE product_components 
( component_id VARCHAR2(40) COLLATE BINARY _CI 
CONSTRAINT product_component_pk PRIMARY KEY 


, product_id CONSTRAINT product_component_fk REFERENCES products(product_id) 
, description VARCHAR2(1000) COLLATE BINARY_CI 
CONSTRAINT product_component_descr_unq UNIQUE 


); 


Note that if you do not specify the data type or the collation for a foreign key column, then they are inherited from 
the parent key column. 


The following statements add a product and its components into the tables: 


INSERT INTO products(product_id, description) 

VALUES(‘BICY0001', 'Men"s bicycle, fr 21", wh 24", gear 3x7'); 

INSERT INTO product_components(component_id, product_id, description) 
VALUES(‘BICY0001_FRAME01', 'BICY0001', ‘Aluminium frame 21"); 
INSERT INTO product_components(component_id, product_id, description) 
VALUES(‘BICY0001_WHEELO1', 'bicy0001', 'Wheels 24"); 

INSERT INTO product_components(component_id, product_id, description) 
VALUES(‘BICY0001_GEAR01', 'Bicy0001', 'Front derailleur 3 chainrings’); 
INSERT INTO product_components(component_id, product_id, description) 
VALUES(‘BICY0001_gear02', 'BiCy0001', 'Rear derailleur 7 chainrings’); 


Note the different case of the product ID in different component rows. Because the primary key on the product ID 
is declared as case-insensitive, all possible letter case combinations of the same ID are considered equal. 


The following statement demonstrates that it is not possible to enter another product with the same description 
differing only by case. It fails with the error ORA-00001: unique constraint ( schema 
.PRODUCT_DESCRIPTION_UNQ) violated. 


INSERT INTO products(product_id, description) 
VALUES(‘BICY0002', 'MEN"S BICYCLE, fr 21", wh 24", gear 3x7'); 


Similarly, the following statement demonstrates that the primary key contraint of the product table is case- 
insensitive and does not allow values differing only by case. It fails with the error ORA-00001: unique constraint ( 
schema .PRODUCT_PK) violated. 


INSERT INTO products(component_id, product_id, description) 
VALUES (‘bicy0001', 'Women'"s bicycle, fr 21", wh 24", gear 2x6’); 


The following statement demonstrates that it is not possible to enter another component with the same description 
differing only by case. It fails with the error ORA-00001: unique constraint ( schema 
.PRODUCT_COMPONENT_DESCR_UNQ) violated. 


INSERT INTO product_components(component_id, product_id, description) 
VALUES(‘BICY0001_gear03', 'BiCy0001', 'REAR DERAILLEUR 7 CHAINRINGS’); 


Attribute-Level Constraints Example 


The following example guarantees that a value exists for both the first_name and last_name attributes of 
the name column in the students table: 


CREATE TYPE person_name AS OBJECT 


(first_name VARCHAR2(30), last_name VARCHAR2(30)); 
/ 


CREATE TABLE students (name person_name, age INTEGER, 
CHECK (name.first_name IS NOT NULL AND 
name.last_name IS NOT NULL)); 


REF Constraint Examples 


The following example creates a duplicate of the sample schema object type cust_address_typ, and then creates a 
table containing a REF column with a SCOPE constraint: 


CREATE TYPE cust_address_typ_new AS OBJECT 
(street_address VARCHAR2(40) 
, postal_code VARCHAR2(10) 
, city VARCHAR2(30) 
, state_province VARCHAR2(10) 
, country_id CHAR(2) 
); 
/ 
CREATE TABLE address_table OF cust_address_typ_new; 


CREATE TABLE customer_addresses ( 
add_id NUMBER, 
address REF cust_address_typ_new 
SCOPE IS address_table); 


The following example creates the same table but with a referential integrity constraint on the REF column that 
references the object identifier column of the parent table: 


CREATE TABLE customer_addresses ( 
add_id NUMBER, 
address REF cust_address_typ REFERENCES address_table); 


The following example uses the type department_typ and the table departments_obj_t. A table with a 
scoped REF is then created. 


CREATE TABLE employees_obj 
(e_name VARCHAR2(100), 
e_number NUMBER, 
e_dept REF department_typ SCOPE IS departments_obj_t ); 


The following statement creates a table with a REF column which has a referential integrity constraint defined on 
it: 


CREATE TABLE employees_obj 
(ename VARCHAR2(100), 
e_number NUMBER, 
e_dept REF department_typ REFERENCES departments_obj_t); 


Explicit Index Control Example 


The following statement shows another way to create a unique (or primary key) constraint that gives you explicit 
control over the index (or indexes) Oracle uses to enforce the constraint: 


CREATE TABLE promotions_var3 

( promo_id NUMBER(6) 

, promo_name VARCHAR2(20) 

, promo_category VARCHAR2(15) 

, promo_cost © NUMBER(10,2) 

, promo_begin_date DATE 

, promo_end_date DATE 

, CONSTRAINT promo_id_u UNIQUE (promo_id, promo_cost) 
USING INDEX (CREATE UNIQUE INDEX promo_ix1 

ON promotions_var3 (promo_id, promo_cost)) 

, CONSTRAINT promo_id_u2 UNIQUE (promo_cost, promo_id) 

USING INDEX promo_ix1); 


This example also shows that you can create an index for one constraint and use that index to create and enable 
another constraint in the same statement. 


DEFERRABLE Constraint Examples 


The following statement creates table games with a NOT DEFERRABLE INITIALLY IMMEDIATE constraint 
check (by default) on the scores column: 


CREATE TABLE games (scores NUMBER CHECK (scores >= 0)); 


To define a unique constraint on a column as INITIALLY DEFERRED DEFERRABLE, issue the following 
statement: 


CREATE TABLE games 
(scores NUMBER, CONSTRAINT ungq_num UNIQUE (scores) 
INITIALLY DEFERRED DEFERRABLE); 


deallocate_unused_clause 


Use the deallocate_unused_clause to explicitly deallocate unused space at the end of a database object segment 
and make the space available for other segments in the tablespace. 


You can deallocate unused space using the following statements: 


ALTER CLUSTER 
ALTER INDEX: to deallocate unused space from the index, an index partition, or an index subpartition 


- ALTER MATERIALIZED VIEW: to deallocate unused space from the overflow segment of an index- 
organized materialized view 


ALTER TABLE: to deallocate unused space from the table, a table partition, a table subpartition, the 
mapping table of an index-organized table, the overflow segment of an index-organized table, or a LOB 
storage segment 


KEEP integer 


Specify the number of bytes above the high water mark that the segment of the database object is to have after 
deallocation. 


If you omit KEEP and the high water mark is above the size of INITIAL and MINEXTENTS, then all 
unused space above the high water mark is freed. When the high water mark is less than the size 


of INITIAL or MINEXTENTS, then all unused space above MINEXTENTS is freed. 


If you specify KEEP, then the specified amount of space is kept and the remaining space is freed. When 
the remaining number of extents is less than MINEXTENTS, then Oracle adjusts MINEXTENTS to the 
new number of extents. If the initial extent becomes smaller than INITIAL, then Oracle 

adjusts INITIAL to the new size. 


In either case, Oracle sets the value of the NEXT storage parameter to the size of the last extent that was 
deallocated. 


file_specification 


Use one of the file_specification forms to specify a file as a data file or temp file, or to specify a group of one or 
more files as a redo log file group. If you are storing your files in Oracle Automatic Storage Management (Oracle 
ASM) disk groups, then you can further specify the file as a disk group file. 


A file_specification can appear in the following statements: 


CREATE CONTROLFILE 
CREATE DATABASE 

- ALTER DATABASE 
CREATE TABLESPACE 
ALTER TABLESPACE 

e ALTER DISKGROUP 


datafile_tempfile_spec 


Use this clause to specify the attributes of data files and temp files if your database storage is in a file system or in 
Oracle ASM disk groups. 


redo_log_file_spec 


Use this clause to specify the attributes of redo log files if your database storage is in a file system or in Oracle 
ASM disk groups. 


filename 


Use filename for files stored in a file system. The filename can specify either a new file or an existing file. For a 
new file: 


- Ifyouare not using Oracle Managed Files, then you must specify both filename and the SIZE clause or 
the statement fails. When you specify a filename without a size, Oracle attempts to reuse an existing file 
and returns an error if the file does not exist. 


If you are using Oracle Managed Files, then filename is optional, as are the remaining clauses of the 
specification. In this case, Oracle Database creates a unique name for the file and saves it in the directory 
specified by one of the following initialization parameters: 

o The DB_RECOVERY_FILE_DEST (for logfiles and control files) 


o The DB_CREATE_FILE_DEST initialization parameter (for any type of file) 
o The DB_CREATE_ONLINE_LOG_DEST_1n initialization parameter, which takes precedence 
over DB_CREATE_FILE_DEST and DB_RECOVERY_FILE_DEST for log files. 


For an existing file, specify the name of either a data file, temp file, or a redo log file member. The filename can 
contain only single-byte characters from 7-bit ASCII or EBCDIC character sets. Multibyte characters are not valid. 


The filename can include a path prefix. If you do not specify such a path prefix, then the database adds the path 
prefix for the default storage location, which is platform dependent. 


A redo log file group can have one or more members (copies). Each filename must be fully specified according to 
the conventions for your operating system. 


The way the database interprets filename also depends on whether you specify it with 
the SIZE and REUSE clauses. 


If you specify filename only, or with the REUSE clause but without the SIZE clause, then the file must 
already exist. 
If you specify filename with SIZE but without REUSE, then the file must be a new file. 


- Ifyou specify filename with both SIZE and REUSE, then the file can be either new or existing. If the file 
exists, then it is reused with the new size. If it does not exist, then the database ignores 
the REUSE keyword and creates a new file of the specified size. 


ASM_filename 


Use a form of ASM_filename for files stored in Oracle ASM disk groups. You can create or refer to data files, 
temp files, and redo log files with this syntax. 


All forms of ASM_filename begin with the plus sign (+) followed by the name of the disk group. You can 
determine the names of all Oracle ASM disk groups by querying the VSASM_DISKGROUP view. 


fully_qualified_file_name 


When you create a file in an Oracle ASM disk group, the file receives a system-generated fully qualified Oracle 
ASM filename. You can use this form only when referring to an existing Oracle ASM file. Therefore, if you are 
using this form during file creation, you must also specify REUSE. 


- db_name is the value of the DB_UNIQUE_NAME initialization parameter. This name is equivalent to the 
name of the database on which the file resides, but the parameter distinguishes between primary and 
standby databases, if both exist. 
file_type and file_type_tag indicate the type of database file. 


- filenumber and incarnation_number are system-generated identifiers to guarantee uniqueness. 
You can determine the fully qualified names of Oracle ASM files by querying the dynamic performance view 
appropriate for the file type (for example V$DATAFILE for data files, VBCONTROLFILE for control files, and so 


on). You can also obtain the filenumber and incarnation_number portions of the fully qualified names by 
querying the VSASM_FILE view. 


Oracle File Types and Oracle ASM File Type Tags 


Oracle ASM 
Oracle ASM file_type Description file_type_tag Comments 
CONTROLFILE Control files and Current — 
backup control Backup 
files 
DATAFILE Data files and data tsname Tablespace into which the file is added 
file copies 
ONLINELOG Online logs group_ group# — 
ARCHIVELOG Archive logs thread_ thread# — 


_seq_ sequence# 


TEMPFILE Temp files tsname Tablespace into which the file is added 


Oracle ASM file_type 


BACKUPSET 


PARAMETERFILE 


DATAGUARDCONFIG 


FLASHBACK 


CHANGETRACKING 


DUMPSET 


XTRANSPORT 


AUTOBACKUP 


numeric_file_name 


Description 


Data file and 
archive log 
backup pieces; 
data file 
incremental 
backup pieces 


Persistent 
parameter files 


Data Guard 
configuration file 
Flashback logs 


Block change 
tracking data 


Data Pump 
dumpset 


Data file convert 


Automatic backup 
files 


Oracle ASM 
file_type_tag 


hasspfile _ 
timestamp 


spfile 


db_unique_name 


log_ log# 


ctf 


user_ obj# _ file# 


tsname 


hasspfile _ 
timestamp 


Comments 


hasspfile can take one of two values: s 
indicates that the backup set includes 
the spfile; n indicates that the backup 
set does not include the spfile. 


Data Guard uses the value of 
the DB_UNIQUE_NAME initialization 
parameter. 


Used during incremental backups 


Dump set files encode the user name, 
the job number that created the dump 
set, and the file number as part of the 
tag. 


hasspfile can take one of two values: s 
indicates that the backup set includes 
the spfile; n indicates that the backup 
set does not include the spfile. 


A numeric Oracle ASM filename is similar to a fully qualified filename except that it uses only the unique 
filenumber.incarnation_number string. You can use this form only to refer to an existing file. Therefore, if you are 
using this form during file creation, you must also specify REUSE. 


incomplete_file_name 


Incomplete Oracle ASM filenames are used during file creation only. If you specify the disk group name alone, 
then Oracle ASM uses the appropriate default template for the file type. For example, if you are creating a data file 
in a CREATE TABLESPACE statement, Oracle ASM uses the default DATAFILE template to create an Oracle 
ASM data file. If you specify the disk group name with a template, then Oracle ASM uses the specified template to 
create the file. In both cases, Oracle ASM also creates a fully qualified filename. 


template_name 


A template is a named collection of attributes. You can create templates and apply them to files in a disk group. 
You can determine the names of all Oracle ASM template names by querying the V$ASM_TEMPLATE data 


dictionary view. 


You can specify template only during file creation. It appears in the incomplete and alias name forms of the 


ASM_filename diagram: 


If you specify template immediately after the disk group name, then Oracle ASM uses the specified 
template to create the file, and gives the file a fully qualified filename. 


If you specify template after specifying an alias, then Oracle ASM uses the specified template to create the 
file, gives the file a fully qualified filename, and also creates the alias so that you can subsequently use it 
to refer to the file. If the alias you specify refers to an existing file, then Oracle ASM ignores the template 
specification unless you also specify REUSE. 


alias_file_name 
An alias is a user-friendly name for an Oracle ASM file. You can use alias filenames during file creation or 


reference. You can specify a template with an alias, but only during file creation. To determine the alias names for 
Oracle ASM files, query the VSASM_ALJAS data dictionary view. 


SIZE Clause 


Specify the size of the file in bytes. Use K, M, G, or T to specify the size in kilobytes, megabytes, gigabytes, or 
terabytes. 


For undo tablespaces, you must specify the SIZE clause for each data file. For other tablespaces, you can 
omit this parameter if the file already exists, or if you are creating an Oracle Managed File. 


- If you omit this clause when creating an Oracle Managed File, then Oracle creates a 100M file. 
The size of a tablespace must be one block greater than the sum of the sizes of the objects contained in it. 
BLOCKSIZE Clause 


Specify BLOCKSIZE to override the operating system-dependent sector size. If you omit this clause, then the 
database uses the operating system-dependent sector size as the block size. 


When you add a redo log file to a 512-byte sector disk or to a 4KB sector disk with 512-byte emulation, the 
blocksize of the new file must be the original platform base block size or 4KB. 


If the redo log file is being added to a 512-byte sector disk, then you must specify 512 or 1024 (or 1K) as 
the block size, depending on your platform. 


- Ifthe redo log file is being added to a 4KB sector disk (native), then you must specify either 4096 or 4K as 
the block size. 


If the redo log file is being added to a 4KB sector disk with 512-byte emulation, then you can specify 
either 512, 1024 (or 1K), or 4096 (or 4K) as the block size, depending on your platform. 


All logs within a log group must have the same block size. Two log groups created on separate disks can have 
different block sizes. However, the mixed configuration introduces overhead at every log switch. Oracle 
recommends that you create all log files with the same block size. 


This clause is useful when the 4K sector size is in use, but you want to optimize disk space use rather than 
performance. In such a case you can override the operating system sector size by specifying BLOCKSIZE 512 or, 
for HP-UX, BLOCKSIZE 1024. 


REUSE 
Specify REUSE to allow Oracle to reuse an existing file. 


- Ifthe file already exists, then Oracle reuses the filename and applies the new size (if you specify SIZE) or 
retains the original size. 


If the file does not exist, then Oracle ignores this clause and creates the file. 
Restriction on the REUSE Clause 
You cannot specify REUSE unless you have specified filename . 
Whenever Oracle uses an existing file, the previous contents of the file are lost. 


autoextend_clause 


The autoextend_clause is valid for data files and temp files but not for redo log files. Use this clause to enable or 
disable the automatic extension of a new or existing data file or temp file. If you omit this clause, then: 


For Oracle Managed Files: 
o If you specify SIZE, then Oracle Database creates a file of the specified size 
with AUTOEXTEND disabled. 


o If you do not specify SIZE, then the database creates a 100M file with AUTOEXTEND enabled. 
When autoextension is required, the database extends the file by its original size or LOOMB, 
whichever is smaller. You can override this default behavior by specifying the NEXT clause. 


For user-managed files, with or without SIZE specified, Oracle creates a file 
with AUTOEXTEND disabled. 


ON 
Specify ON to enable autoextend. 
OFF 


Specify OFF to turn off autoextend if is turned on. When you turn off autoextend, the values 
of NEXT and MAXSIZE are set to zero. If you turn autoextend back on in a subsequent statement, then you must 
reset these values. 


NEXT 


Use the NEXT clause to specify the size in bytes of the next increment of disk space to be allocated automatically 
when more extents are required. The default is the size of one data block. 


MAXSIZE 
Use the MAXSIZE clause to specify the maximum disk space allowed for automatic extension of the data file. 
UNLIMITED 


Use the UNLIMITED clause if you do not want to limit the disk space that Oracle can allocate to the data file or 
temp file. 


Restriction on the autoextend_clause 


You cannot specify this clause as part of the datafile_tempfile_spec ina CREATE CONTROLFILE statement or 
in an ALTER DATABASE CREATE DATAFILE clause. 


Examples 
Specifying a Log File: Example 


The following statement creates a database named payable that has two redo log file groups, each with two 
members, and one data file: 


CREATE DATABASE payable 
LOGFILE GROUP 1 (‘diska:log1.log’, 'diskb:log1.log') SIZE 50K, 
GROUP 2 (‘diska:log2.log’, 'diskb:log2.log') SIZE 50K 
DATAFILE 'diskc:dbone.dbf' SIZE 30M; 


The first file specification in the LOGFILE clause specifies a redo log file group with the GROUP value 1. This 
group has members named ‘diska:log1.log' and ‘diskb:log1.log', each 50 kilobytes in size. 


The second file specification in the LOGFILE clause specifies a redo log file group with the GROUP value 2. This 
group has members named ‘diska:log2.log' and ‘diskb:log2.log', also 50 kilobytes in size. 


The file specification in the DATAFILE clause specifies a data file named ‘diskc:dbone.dbf', 30 megabytes in size. 


Each file specification specifies a value for the SIZE parameter and omits the REUSE clause, so none of these files 
can already exist. Oracle must create them. 


Adding a Log File: Example 


The following statement adds another redo log file group with two members to the payable database: 


ALTER DATABASE payable 
ADD LOGFILE GROUP 3 (‘diska:log3.log’, 'diskb:log3.log') 
SIZE 50K REUSE; 


The file specification in the ADD LOGFILE clause specifies a new redo log file group with the GROUP value 3. 
This new group has members named ‘diska:log3.log' and 'diskb:log3.log', each 50 kilobytes in size. Because the 
file specification specifies the REUSE clause, each member can (but need not) already exist. 


The following statement adds a logfile group 5 with member log files on migration target 
disks 4k_disk_a and 4k_disk_b. After executing this statement, you can switch existing log files on disks with 512- 
byte block size to logs with 4K block size using the switch_logfile_clause . 


ALTER DATABASE ADD LOGFILE GROUP 5 
(‘'4k_disk_a:log5.log', '4k_disk_b:log5.log') 
SIZE 100M BLOCKSIZE 4096 REUSE; 

Specifying a Data File: Example 


The following statement creates a tablespace named stocks that has three data files: 


CREATE TABLESPACE stocks 
DATAFILE 'stock1.dbf' SIZE 10M, 
‘stock2.dbf' SIZE 10M, 
‘stock3.dbf' SIZE 10M; 


The file specifications for the data files specify files named 'diskc:stock1.dbf’, 'diskc:stock2.dbf', and 
‘diskc:stock3.dbf'. 


Adding a Data File: Example 


The following statement alters the stocks tablespace and adds a new data file: 


ALTER TABLESPACE stocks 
ADD DATAFILE 'stock4.dbf' SIZE 10M REUSE; 


The file specification specifies a data file named 'stock4.dbf'. If the filename does not exist, then Oracle simply 
ignores the REUSE keyword. 

Using a Fully Qualified Oracle ASM Data File Name: Example 

When using Oracle ASM, the following syntax shows how to use the fully_qualified_file_name clause to bring 


online a data file in a hypothetical database, testdb: 


ALTER DATABASE testdb 
DATAFILE '+dgroup_01/testdb/datafile/system.261.1' ONLINE; 


logging_clause 


The logging_clause lets you specify whether certain DML operations will be logged in the redo log file 
(LOGGING) or not (NOLOGGING). 


You can specify the logging_clause in the following statements: 
e CREATE TABLE and ALTER TABLE: for logging of the table, a table partition, a LOB segment, or the 
overflow segment of an index-organized table. 
CREATE INDEX and ALTER INDEX: for logging of the index or an index partition. 


e CREATE MATERIALIZED VIEW and ALTER MATERIALIZED VIEW: for logging of the materialized 
view, one of its partitions, or a LOB segment. 


CREATE MATERIALIZED VIEW LOG and ALTER MATERIALIZED VIEW LOG: for logging of the 
materialized view log or one of its partitions. 


e CREATE TABLESPACE and ALTER TABLESPACE: to set or modify the default logging characteristics 
for all objects created in the tablespace. 


CREATE PLUGGABLE DATABASE and ALTER PLUGGABLE DATABASE: to set or modify the 
default logging characteristics for all tablespaces created in the pluggable database (PDB). 
You can also specify LOGGING or NOLOGGING for the following operations: 


- Rebuilding an index (using CREATE INDEX ... REBUILD) 
Moving a table (using ALTER TABLE ... MOVE) 


DML : 


e Direct-path INSERT (serial or parallel) resulting either from an INSERT or 
a MERGE statement. NOLOGGING is not applicable to any UPDATE operations resulting from 
the MERGE statement. 


Direct Loader (SQL*Loader) 

DDL: 
CREATE TABLE ... AS SELECT (In NOLOGGING mode, the creation of the table will be logged, but 
direct-path inserts will not be logged.) 


CREATE TABLE ... LOB_storage_clause ... LOB_parameters 
... CACHE | NOCACHE | CACHE READS 


ALTER TABLE ... LOB_storage_clause ... LOB_parameters 
... CACHE | NOCACHE | CACHE READS (to specify logging of newly created LOB columns) 


ALTER TABLE ... modify_LOB_storage_clause ... modify_LOB_parameters 
... CACHE | NOCACHE | CACHE READS (to change logging of existing LOB columns) 


- ALTER TABLE ... MOVE 


ALTER TABLE ... (all partition operations that involve data movement) 
o ALTER TABLE ... ADD PARTITION (hash partition only) 


o ALTER TABLE ... MERGE PARTITIONS 
o ALTER TABLE ... SPLIT PARTITION 
o ALTER TABLE ... MOVE PARTITION 
o ALTER TABLE ... MODIFY PARTITION ... ADD SUBPARTITION 
o ALTER TABLE ... MODIFY PARTITION ... COALESCE SUBPARTITION 
- CREATE INDEX 
ALTER INDEX ... REBUILD 
ALTER INDEX ... REBUILD [SUB]PARTITION 
+ ALTER INDEX ... SPLIT PARTITION 


For objects other than LOBs , if you omit this clause, then the logging attribute of the object defaults to the 
logging attribute of the tablespace in which it resides. 


For LOBs , if you omit this clause, then: 


- Ifyou specify CACHE, then LOGGING is used (because you cannot have CACHE NOLOGGING). 
If you specify NOCACHE or CACHE READS, then the logging attribute defaults to the logging attribute 
of the tablespace in which it resides. 


NOLOGGING does not apply to LOBs that are stored internally (in the table with row data). If you 
specify NOLOGGING for LOBs with values less than 4000 bytes and you have not disabled STORAGE IN ROW, 
then Oracle ignores the NOLOGGING specification and treats the LOB data the same as other table data. 


parallel_clause 


The parallel_clause lets you parallelize the creation of a database object and set the default degree of parallelism 
for subsequent queries of and DML operations on the object. 


You can specify the parallel_clause in the following statements: 


CREATE TABLE: to set parallelism for the table. 


ALTER TABLE : 
o To change parallelism for the table 


o To parallelize the operations of adding, coalescing, exchanging, merging, splitting, truncating, 
dropping, or moving a table partition 


CREATE CLUSTER and ALTER CLUSTER: to set or alter parallelism for a cluster. 
- CREATE INDEX: to set parallelism for the index. 


ALTER INDEX : 
o To change parallelism for the index 


o To parallelize the rebuilding of the index or the splitting of an index partition 
CREATE MATERIALIZED VIEW: to set parallelism for the materialized view. 


ALTER MATERIALIZED VIEW : 
o To change parallelism for the materialized view 


o To parallelize the operations of adding, coalescing, exchanging, merging, splitting, truncating, 
dropping, or moving a materialized view partition 


o To parallelize the operations of adding or moving materialized view subpartitions 
e CREATE MATERIALIZED VIEW LOG: to set parallelism for the materialized view log. 


ALTER MATERIALIZED VIEW LOG : 
e To change parallelism for the materialized view log 


o To parallelize the operations of adding, coalescing, exchanging, merging, splitting, truncating, 
dropping, or moving a materialized view log partition 


ALTER DATABASE ... RECOVER: to recover the database. 
ALTER DATABASE ... standby_database_clauses : to parallelize operations on the standby database. 


NOPARALLEL 

Specify NOPARALLEL for serial execution. This is the default. 
PARALLEL 

Specify PARALLEL for parallel execution. 


If PARALLEL_DEGREE_POLICY is set to MANUAL, then the optimizer calculates a degree of 
parallelism equal to the number of CPUs available on all participating instances times the value of 


the PARALLEL_THREADS_PER_CPU initialization parameter. 


If PARALLEL_DEGREE_POLICY is set to LIMITED, then the optimizer determines the best degree of 
parallelism. 


PARALLEL integer 


Specification of integer indicates the degree of parallelism , which is the number of parallel threads used in the 
parallel operation. Each parallel thread may use one or two parallel execution servers. 


Notes on the parallel_clause 


The following notes apply to the parallel_clause : 


Parallelism is disabled for DML operations on tables on which you have defined a trigger or referential 
integrity constraint. 


Parallelism is not supported for UPDATE or DELETE operations on index-organized tables. 


When you specify the parallel_clause during creation of a table, if the table contains any columns of 
LOB or user-defined object type, then subsequent INSERT, UPDATE, DELETE or MERGE operations 
that modify the LOB or object type column are executed serially without notification. Subsequent queries, 
however, will be executed in parallel. 


A parallel hint overrides the effect of the parallel_clause . 


DML statements and CREATE TABLE ... AS SELECT statements that reference remote objects can run in 
parallel. However, the remote object must really be on a remote database. The reference cannot loop back 
to an object on the local database, for example, by way of a synonym on the remote database pointing 
back to an object on the local database. 


DML operations on tables with LOB columns can be parallelized. However, intrapartition parallelism is 
not supported. 


physical_attributes_clause 


The physical_attributes_clause lets you specify the value of the PCTFREE, PCTUSED, 
and INITRANS parameters and the storage characteristics of a table, cluster, index, or materialized view. 


You can specify the physical_attributes_clause in the following statements: 


CREATE CLUSTER and ALTER CLUSTER: to set or change the physical attributes of the cluster and all 
tables in the cluster. 


CREATE TABLE: to set the physical attributes of the table, a table partition, the OIDINDEX of an object 
table, or the overflow segment of an index-organized table. 


ALTER TABLE: to change the physical attributes of the table, the default physical attributes of future 
table partitions, or the physical attributes of existing table partitions. The following restrictions apply: 
e You cannot specify physical attributes for a temporary table. 


o You cannot specify physical attributes for a clustered table. Tables in a cluster inherit the physical 
attributes of the cluster. 
CREATE INDEX: to set the physical attributes of an index or index partition. 
ALTER INDEX: to change the physical attributes of the index, the default physical attributes of future 
index partitions, or the physical attributes of existing index partitions. 
CREATE MATERIALIZED VIEW: to set the physical attributes of the materialized view, one of its 
partitions, or the index Oracle Database generates to maintain the materialized view. 


ALTER MATERIALIZED VIEW: to change the physical attributes of the materialized view, the default 
physical attributes of future partitions, the physical attributes of an existing partition, or the index Oracle 
creates to maintain the materialized view. 


CREATE MATERIALIZED VIEW LOG and ALTER MATERIALIZED VIEW LOG: to set or change the 
physical attributes of the materialized view log. 


PCTFREE integer 


Specify a whole number representing the percentage of space in each data block of the database object reserved for 
future updates to rows of the object. The value of PCTFREE must be a value from 0 to 99. A value of 0 means that 
the entire block can be filled by inserts of new rows. The default value is 10. This value reserves 10% of each 
block for updates to existing rows and allows inserts of new rows to fill a maximum of 90% of each block. 


PCTFREE has the same function in the statements that create and alter tables, partitions, clusters, indexes, 
materialized views, materialized view logs, and zone maps. The combination 

of PCTFREE and PCTUSED determines whether new rows will be inserted into existing data blocks or into new 
blocks. 


Restriction on the PCTFREE Clause 


When altering an index, you can specify this parameter only in the modify_index_default_attrs clause and the 
split_index_partition clause. 


PCTUSED integer 


Specify a whole number representing the minimum percentage of used space that Oracle maintains for each data 
block of the database object. PCTUSED is specified as a positive integer from 0 to 99 and defaults to 40. 


PCTUSED has the same function in the statements that create and alter tables, partitions, clusters, materialized 
views, materialized view logs, and zone maps. 


PCTUSED is not a valid table storage characteristic for an index-organized table. 


The sum of PCTFREE and PCTUSED must be equal to or less than 100. You can 
use PCTFREE and PCTUSED together to utilize space within a database object more efficiently. 


Restrictions on the PCTUSED Clause 
The PCTUSED parameter is subject to the following restrictions: 


You cannot specify this parameter for an index or for the index segment of an index-organized table. 


This parameter is not useful and is ignored for objects with automatic segment-space management. 


How PCTFREE and PCTUSED Work Together 


In a newly allocated data block, the space available for inserts is the block size minus the sum of the block 
overhead and free space (PCTFREE). Updates to existing data can use any available space in the block. Therefore, 
updates can reduce the available space of a block to less than PCTFREE. 


After a data block is filled to the limit determined by PCTFREE, Oracle Database considers the block unavailable 
for the insertion of new rows until the percentage of that block falls beneath the parameter PCTUSED. Until this 
value is achieved, Oracle Database uses the free space of the data block only for updates to rows already contained 
in the data block. A block becomes a candidate for row insertion when its used space falls below PCTUSED. 


INITRANS integer 


Specify the initial number of concurrent transaction entries allocated within each data block allocated to the 
database object. This value can range from 1 to 255 and defaults to 1, with the following exceptions: 


The default INITRANS value for a cluster is 2 or the default INITRANS value of the tablespace in which 
the cluster resides, whichever is greater. 


- The default value for an index is 2. 
In general, you should not change the INITRANS value from its default. 


Each transaction that updates a block requires a transaction entry in the block. This parameter ensures that a 
minimum number of concurrent transactions can update the block and helps avoid the overhead of dynamically 


allocating a transaction entry. 


The INITRANS parameter serves the same purpose in the statements that create and alter tables, partitions, 
clusters, indexes, materialized views, and materialized view logs. 


MAXTRANS Parameter 


In earlier releases, the MAXTRANS parameter determined the maximum number of concurrent update 
transactions allowed for each data block in the segment. This parameter has been deprecated. Oracle now 
automatically allows up to 255 concurrent update transactions for any data block, depending on the available space 
in the block. 


Existing objects for which a value of MAXTRANS has already been set retain that setting. However, if you 
attempt to change the value for MAXTRANS, Oracle ignores the new specification and substitutes the value 255 
without returning an error. 


storage_clause 


The storage_clause lets you specify storage characteristics for the table, object table OIDINDEX, partition, LOB 
data segment, or index-organized table overflow data segment. This clause has performance ramifications for large 
tables. Storage should be allocated to minimize dynamic allocation of additional space. 


size_clause 


The size_clause lets you specify a number of bytes, kilobytes (K), megabytes (M), gigabytes (G), terabytes (T), 
petabytes (P), or exabytes (E) in any statement that lets you establish amounts of disk or memory space. 


storage_clause 


The storage_clause lets you specify how Oracle Database should store a permanent database object. Storage 
parameters for temporary segments always use the default storage parameters for the associated tablespace. 
Storage parameters affect both how long it takes to access data stored in the database and how efficiently space in 
the database is used. 


When you create a cluster, index, materialized view, materialized view log, rollback segment, table, LOB, varray, 
nested table, or partition, you can specify values for the storage parameters for the segments allocated to these 
objects. If you omit any storage parameter, then Oracle uses the value of that parameter specified for the tablespace 
in which the object resides. If no value was specified for the tablespace, then the database uses default values. 


When you alter a cluster, index, materialized view, materialized view log, rollback segment, table, varray, nested 
table, or partition, you can change the values of storage parameters. The new values affect only future extent 
allocations. 


The storage_clause is part of the physical_attributes_clause , so you can specify this clause in any of the 
statements where you can specify the physical attributes clause. In addition, you can specify the storage_clause 
in the following statements: 


e CREATE CLUSTER and ALTER CLUSTER: to set or change the storage characteristics of the cluster 
and all tables in the cluster . 


CREATE INDEX and ALTER INDEX: to set or change the storage characteristics of an index segment 
created for a table index or index partition or an index segment created for an index used to enforce 
a primary key or unique constraint . 


- The ENABLE ... USING INDEX clause of CREATE TABLE or ALTER TABLE: to set or change the 
storage characteristics of an index created by the system to enforce a primary key or unique 
constraint . 


CREATE MATERIALIZED VIEW and ALTER MATERIALIZED VIEW: to set or change the storage 
characteristics of a materialized view, one of its partitions, or the index Oracle generates to maintain 
the materialized view . 


CREATE MATERIALIZED VIEW LOG and ALTER MATERIALIZED VIEW LOG: to set or change the 
storage characteristics of the materialized view log . 


CREATE ROLLBACK SEGMENT and ALTER ROLLBACK SEGMENT: to set or change the storage 
characteristics of a rollback segment . 


CREATE TABLE and ALTER TABLE: to set the storage characteristics of a LOB or varray data 
segment of the nonclustered table or one of its partitions or subpartitions, or the storage table of a 
nested table . 


CREATE TABLESPACE and ALTER TABLESPACE: to set or change the default storage characteristics 
for objects created in the tablespace . Changes to tablespace storage parameters affect only new objects 
created in the tablespace or new extents allocated for a segment. 


constraint : to specify storage for the index (and its partitions, if it is a partitioned index) used to 
enforce the constraint . 


INITIAL 


Specify the size of the first extent of the object. Oracle allocates space for this extent when you create the schema 
object. 


In locally managed tablespaces, Oracle uses the value of INITIAL, in conjunction with the type of local 
management—AUTOALLOCATE or UNIFORM—and the values 
of MINEXTENTS, NEXT and PCTINCREASE, to determine the initial size of the segment. 


e With AUTOALLOCATE extent management, Oracle uses the INITIAL setting to optimize the number of 
extents allocated. Extents of 64K, 1M, 8M, and 64M can be allocated. During segment creation, the 
system chooses the greatest of these four sizes that is equal to or smaller than INITIAL, and allocates as 
many extents of that size as are needed to reach the INITIAL setting. For example, if you set INITIAL to 
4M, then the database creates four 1M extents. 


For UNIFORM extent management, the number of extents is determined from initial segment size and the 
uniform extent size specified at tablespace creation time. For example, in a uniform locally managed 
tablespace with 1M extents, if you specify an INITIAL value of 5M, then Oracle creates five 1M extents. 


Consider this comparison: With AUTOALLOCATE, if you set INITAL to 72K, then the initial segment 
size will be 128K (greater than INITIAL). The database cannot allocate an extent smaller than 64K, so it 
must allocate two 64K extents. If you set INITIAL to 72K with a UNIFORM extent size of 24K, then the 
database will allocate three 24K extents to equal 72K. 


In dictionary managed tablespaces, the default initial extent size is 5 blocks, and all subsequent extents are rounded 
to 5 blocks. If MINIMUM EXTENT was specified at tablespace creation time, then the extent sizes are rounded to 
the value of MINIMUM EXTENT. 


Restriction on INITIAL 

You cannot specify INITIAL in an ALTER statement. 

NEXT 

Specify in bytes the size of the next extent to be allocated to the object. 


In locally managed tablespaces, any user-supplied value for NEXT is ignored and the size of NEXT is determined 
by Oracle if the tablespace is set for autoallocate extent management. In UNIFORM tablespaces, the size 
of NEXT is the uniform extent size specified at tablespace creation time. 


In dictionary-managed tablespaces, the default value is the size of 5 data blocks. The minimum value is the size of 
1 data block. The maximum value depends on your operating system. Oracle rounds values up to the next multiple 
of the data block size for values less than 5 data blocks. For values greater than 5 data blocks, Oracle rounds up to 
a value that minimizes fragmentation. 


PCTINCREASE 


In locally managed tablespaces, Oracle Database uses the value of PCTINCREASE during segment creation to 
determine the initial segment size and ignores this parameter during subsequent space allocation. 


In dictionary-managed tablespaces, specify the percent by which the third and subsequent extents grow over the 
preceding extent. The default value is 50, meaning that each subsequent extent is 50% larger than the preceding 
extent. The minimum value is 0, meaning all extents after the first are the same size. The maximum value depends 
on your operating system. Oracle rounds the calculated size of each new extent to the nearest multiple of the data 
block size. If you change the value of the PCTINCREASE parameter by specifying it in an ALTER statement, then 
Oracle calculates the size of the next extent using this new value and the size of the most recently allocated extent. 


Restriction on PCTINCREASE 


You cannot specify PCTINCREASE for rollback segments. Rollback segments always have 
a PCTINCREASE value of 0. 


MINEXTENTS 


In locally managed tablespaces, Oracle Database uses the value of MINEXTENTS in conjunction 
with PCTINCREASE, INITIAL and NEXT to determine the initial segment size. 


In dictionary-managed tablespaces, specify the total number of extents to allocate when the object is created. The 
default and minimum value is 1, meaning that Oracle allocates only the initial extent, except for rollback segments, 
for which the default and minimum value is 2. The maximum value depends on your operating system. 


- Ina locally managed tablespace, MINEXTENTS is used to compute the initial amount of space allocated, 
which is equal to INITIAL * MINEXTENTS. Thereafter this value is set to 1, which is reflected in 
the DBA_SEGMENTS view. 


In a dictionary-managed tablespace, MINEXTENTS is simply the minimum number of extents that must 
be allocated to the segment. 


If the MINEXTENTS value is greater than 1, then Oracle calculates the size of subsequent extents based on the 
values of the INITIAL, NEXT, and PCTINCREASE storage parameters. 


When changing the value of MINEXTENTS by specifying it in an ALTER statement, you can reduce the value 
from its current value, but you cannot increase it. Resetting MINEXTENTS to a smaller value might be useful, for 
example, before a TRUNCATE ... DROP STORAGE statement, if you want to ensure that the segment will 
maintain a minimum number of extents after the TRUNCATE operation. 


Restrictions on MINEXTENTS 
The MINEXTENTS storage parameter is subject to the following restrictions: 


MINEXTENTS is not applicable at the tablespace level. 


You cannot change the value of MINEXTENTS in an ALTER statement or for an object that resides in a 
locally managed tablespace. 


MAXEXTENTS 


This storage parameter is valid only for objects in dictionary-managed tablespaces. Specify the total number of 
extents, including the first, that Oracle can allocate for the object. The minimum value is 1 except for rollback 
segments, which always have a minimum of 2. The default value depends on your data block size. 


Restriction on MAXEXTENTS 


MAXEXTENTS is ignored for objects residing in a locally managed tablespace, unless the value 
of ALLOCATION_TYPE is USER for the tablespace in the DBA_TABLESPACES data dictionary view. 


UNLIMITED 


Specify UNLIMITED if you want extents to be allocated automatically as needed. Oracle recommends this setting 
as a way to minimize fragmentation. 


Do not use this clause for rollback segments. Doing so allows the possibility that long-running rogue DML 
transactions will continue to create new extents until a disk is full. 


MAXSIZE 


The MAXSIZE clause lets you specify the maximum size of the storage element. For LOB storage, MAXSIZE has 
the following effects 


- Ifyou specify RETENTION MAX in LOB_parameters , then the LOB segment increases to the specified 
size before any space can be reclaimed from undo space. 


If you specify RETENTION AUTO, MIN, or NONE in LOB_parameters , then the specified size is a hard 
limit on the LOB segment size and has no bearing on undo retention. 


UNLIMITED 


Use the UNLIMITED clause if you do not want to limit the disk space of the storage element. This clause is not 
compatible with a specification of RETENTION MAX in LOB_parameters . If you specify both, then the 
database uses RETENTION AUTO and MAXSIZE UNLIMITED. 


FREELISTS 


In tablespaces with manual segment-space management, Oracle Database uses the FREELISTS storage parameter 
to improve performance of space management in OLTP systems by increasing the number of insert points in the 
segment. In tablespaces with automatic segment-space management, this parameter is ignored, because the 
database adapts to varying workload. 


In tablespaces with manual segment-space management, for objects other than tablespaces and rollback segments, 
specify the number of free lists for each of the free list groups for the table, partition, cluster, or index. The default 
and minimum value for this parameter is 1, meaning that each free list group contains one free list. The maximum 
value of this parameter depends on the data block size. If you specify a FREELISTS value that is too large, then 
Oracle returns an error indicating the maximum value. 


Restriction on FREELISTS 


You can specify FREELISTS in the storage_clause of any statement except when creating or altering a 
tablespace or rollback segment. 


FREELIST GROUPS 


In tablespaces with manual segment-space management, Oracle Database uses the value of this storage parameter 
to statically partition the segment free space in an Oracle Real Application Clusters environment. This partitioning 
improves the performance of space allocation and deallocation by avoiding inter instance transfer of segment 
metadata. In tablespaces with automatic segment-space management, this parameter is ignored, because Oracle 
dynamically adapts to inter instance workload. 


In tablespaces with manual segment-space management, specify the number of groups of free lists for the database 
object you are creating. The default and minimum value for this parameter is 1. Oracle uses the instance number of 
Oracle Real Application Clusters (Oracle RAC) instances to map each instance to one free list group. 


Each free list group uses one database block. Therefore: 


- Ifyou do not specify a large enough value for INITIAL to cover the minimum value plus one data block 
for each free list group, then Oracle increases the value of INITIAL the necessary amount. 


If you are creating an object in a uniform locally managed tablespace, and the extent size is not large 
enough to accommodate the number of freelist groups, then the create operation will fail. 
Restriction on FREELIST GROUPS 


You can specify the FREELIST GROUPS parameter only 
in CREATE TABLE, CREATE CLUSTER, CREATE MATERIALIZED VIEW, CREATE MATERIALIZED VIE 
W LOG, and CREATE INDEX statements. 


OPTIMAL 


The OPTIMAL keyword is relevant only to rollback segments. It specifies an optimal size in bytes for a rollback 
segment. 


Oracle tries to maintain this size for the rollback segment by dynamically deallocating extents when their data is 
no longer needed for active transactions. Oracle deallocates as many extents as possible without reducing the total 
size of the rollback segment below the OPTIMAL value. 


The value of OPTIMAL cannot be less than the space initially allocated by the MINEXTENTS, INITIAL, NEXT, 
and PCTINCREASE parameters. The maximum value depends on your operating system. Oracle rounds values up 
to the next multiple of the data block size. 


NULL 


Specify NULL for no optimal size for the rollback segment, meaning that Oracle never deallocates the extents of 
the rollback segment. This is the default behavior. 


BUFFER_POOL 


The BUFFER_POOL clause lets you specify a default buffer pool or cache for a schema object. All blocks for the 
object are stored in the specified cache. 


If you define a buffer pool for a partitioned table or index, then the partitions inherit the buffer pool from 
the table or index definition unless overridden by a partition-level definition. 
- For an index-organized table, you can specify a buffer pool separately for the index segment and the 
overflow segment. 
KEEP 


Specify KEEP to put blocks from the segment into the KEEP buffer pool. Maintaining an appropriately 

sized KEEP buffer pool lets Oracle retain the schema object in memory to avoid I/O operations. KEEP takes 
precedence over any NOCACHE clause you specify for a table, cluster, materialized view, or materialized view 
log. 


RECYCLE 
Specify RECYCLE to put blocks from the segment into the RECYCLE pool. An appropriately 


sized RECYCLE pool reduces the number of objects whose default pool is the RECYCLE pool from taking up 
unnecessary cache space. 


DEFAULT 


Specify DEFAULT to indicate the default buffer pool. This is the default for objects not assigned 
to KEEP or RECYCLE. 


FLASH_CACHE 


The FLASH_CACHE clause lets you override the automatic buffer cache policy and specify how specific schema 
objects are cached in flash memory. To use this clause, Database Smart Flash Cache (flash cache) must be 
configured on your system. The flash cache is an extension of the database buffer cache that is stored on a flash 
disk, a storage device that uses flash memory. Because flash memory is faster than magnetic disks, the database 
can improve performance by caching buffers in the flash cache instead of reading from magnetic disk. 


KEEP 


Specify KEEP if you want the schema object buffers to remain cached in the flash cache as long as the flash cache 
is large enough. 
NONE 


Specify NONE to ensure that the schema object buffers are never cached in the flash cache. This allows you to 
reserve the flash cache space for more frequently accessed objects. 


DEFAULT 


Specify DEFAULT if you want the schema object buffers to be written to the flash cache when they are aged out of 
main memory, and then be aged out of the flash cache with the standard buffer cache replacement algorithm. This 
is the default if flash cache is configured and you do not specify KEEP or NONE. 


ENCRYPT 


This clause is valid only when you are creating a tablespace. Specify ENCRYPT to encrypt the entire tablespace. 
You must also specify the ENCRYPTION clause in the CREATE TABLESPACE statement. 


Example 
Specifying Table Storage Attributes: Example 


The following statement creates a table and provides storage parameter values: 


CREATE TABLE divisions 
(div_no NUMBER(2), 
div_name VARCHAR2(14), 
location VARCHAR2(13) ) 
STORAGE (INITIAL 8M MAXSIZE 1G); 


The following statement queries the table for the size of the first extent: 


SELECT INITIAL_EXTENT FROM USER_TABLES WHERE TABLE_NAME='DIVISIONS'; 


INITIAL_EXTENT 


8388608 


Oracle allocates space for the table based on the STORAGE parameter values as follows: 


The INITIAL value is 8M, so the size of the first extent is 8 megabytes. 
- The MAXSIZE value is 1G, so the maximum size of the storage element is 1 gigabyte. 
SQL Queries and Subqueries 


This section describes SQL queries and subqueries. 
This chapter contains these sections: 


Queries and Subqueries 
- Creating Simple Queries 
Hierarchical Queries 
The UNION [ALL], INTERSECT, MINUS Operators 
- Sorting Query Results 
Joins 
Using Subqueries 
- Unnesting of Nested Subqueries 
Selecting from the DUAL Table 
- Distributed Queries 


Queries and Subqueries 


A query is an operation that retrieves data from one or more tables or views. In this reference, a top- 
level SELECT statement is called a query , and a query nested within another SQL statement is called a 
subquery . 


This section describes some types of queries and subqueries and how to use them. The top level of the syntax is 
shown in this chapter. 


Creating Simple Queries 


The list of expressions that appears after the SELECT keyword and before the FROM clause is called the select 
list . Within the select list, you specify one or more columns in the set of rows you want Oracle Database to return 
from one or more tables, views, or materialized views. The number of columns, as well as their data type and 
length, are determined by the elements of the select list. 


If two or more tables have some column names in common, then you must qualify column names with names of 
tables. Otherwise, fully qualified column names are optional. However, it is always a good idea to qualify table 
and column references explicitly. Oracle often does less work with fully qualified table and column names. 


You can use a column alias, c_alias , to label the immediately preceding expression in the select list so that the 
column is displayed with a new heading. The alias effectively renames the select list item for the duration of the 
query. The alias can be used in the ORDER BY clause, but not other clauses in the query. 


You can use comments in a SELECT statement to pass instructions, or hints , to the Oracle Database optimizer. 
The optimizer uses hints to choose an execution plan for the statement. 


Hierarchical Queries 


If a table contains hierarchical data, then you can select rows in a hierarchical order using the hierarchical query 
clause: 


CONNECT BY specifies the relationship between parent rows and child rows of the hierarchy. 


The NOCYCLE parameter instructs Oracle Database to return rows from a query even if 
a CONNECT BY loop exists in the data. Use this parameter along with 
the CONNECT_BY_ISCYCLE pseudocolumn to see which rows contain the loop. 


- Ina hierarchical query, one expression in condition must be qualified with the PRIOR operator to refer to 
the parent row. For example, 


... PRIOR expr = expr 
or 
... expr = PRIOR expr 


If the CONNECT BY condition is compound, then only one condition requires the PRIOR operator, 
although you can have multiple PRIOR conditions. For example: 


CONNECT BY last_name != 'King' AND PRIOR employee_id = manager_id ... 
CONNECT BY PRIOR employee_id = manager_id and 
PRIOR account_mgr_id = customer_id ... 


PRIOR is a unary operator and has the same precedence as the unary + and - arithmetic operators. It 
evaluates the immediately following expression for the parent row of the current row in a hierarchical 
query. 

PRIOR is most commonly used when comparing column values with the equality operator. 

(The PRIOR keyword can be on either side of the operator.) PRIOR causes Oracle to use the value of the 
parent row in the column. Operators other than the equal sign (=) are theoretically possible 

in CONNECT BY clauses. However, the conditions created by these other operators can result in an 
infinite loop through the possible combinations. In this case Oracle detects the loop at run time and 
returns an error. 


Both the CONNECT BY condition and the PRIOR expression can take the form of an uncorrelated subquery. 
However, CURRVAL and NEXTVAL are not valid PRIOR expressions, so the PRIOR expression cannot refer to a 
sequence. 


You can further refine a hierarchical query by using the CONNECT_BY_ROOT operator to qualify a column in 
the select list. This operator extends the functionality of the CONNECT BY [PRIOR] condition of hierarchical 
queries by returning not only the immediate parent row but all ancestor rows in the hierarchy. 


Oracle processes hierarchical queries as follows: 


- A join, if present, is evaluated first, whether the join is specified in the FROM clause or 
with WHERE clause predicates. 


The CONNECT BY condition is evaluated. 


- Any remaining WHERE clause predicates are evaluated. 
Oracle then uses the information from these evaluations to form the hierarchy using the following steps: 


1. Oracle selects the root row(s) of the hierarchy—those rows that satisfy the START WITH condition. 


2. Oracle selects the child rows of each root row. Each child row must satisfy the condition of 
the CONNECT BY condition with respect to one of the root rows. 


3. Oracle selects successive generations of child rows. Oracle first selects the children of the rows returned 
in step 2, and then the children of those children, and so on. Oracle always selects children by evaluating 
the CONNECT BY condition with respect to a current parent row. 


4. If the query contains a WHERE clause without a join, then Oracle eliminates all rows from the hierarchy 
that do not satisfy the condition of the WHERE clause. Oracle evaluates this condition for each row 
individually, rather than removing all the children of a row that does not satisfy the condition. 


Hierarchical Queries 


ROOT 


To find the children of a parent row, Oracle evaluates the PRIOR expression of the CONNECT BY condition for 
the parent row and the other expression for each row in the table. Rows for which the condition is true are the 
children of the parent. The CONNECT BY condition can contain other conditions to further filter the rows selected 
by the query. 


If the CONNECT BY condition results in a loop in the hierarchy, then Oracle returns an error. A loop occurs if one 
row is both the parent (or grandparent or direct ancestor) and a child (or a grandchild or a direct descendent) of 
another row. 

Hierarchical Query Examples 

CONNECT BY Example 


The following hierarchical query uses the CONNECT BY clause to define the relationship between employees and 
managers: 


SELECT employee_id, last_name, manager_id 
FROM employees 
CONNECT BY PRIOR employee_id = manager_id; 


EMPLOYEE_ID LAST_NAME MANAGER_ID 
101 Kochhar 100 
108 Greenberg 101 
109 Faviet 108 
110 Chen 108 
111 Sciarra 108 
112 Urman 108 
113 Popp 108 
200 Whalen 101 
203 Mavris 101 
204 Baer 101 


LEVEL Example 


The next example is similar to the preceding example, but uses the LEVEL pseudocolumn to show parent and 
child rows: 


SELECT employee_id, last_name, manager_id, LEVEL 
FROM employees 
CONNECT BY PRIOR employee_id = manager_id; 


EMPLOYEE_ID LAST_NAME MANAGER ID LEVEL 
101 Kochhar 100 1 
108 Greenberg 101 2 
109 Faviet 108 3 
110 Chen 108 3 
111 Sciarra 108 3 
112 Urman 108 3 
113 Popp 108 3 
200 Whalen 101 2 
203 Mavris 101 2 
204 Baer 101 2 
205 Higgins 101 2 
206 Gietz 205 3 
102 De Haan 100 1 
START WITH Examples 


The next example adds a START WITH clause to specify a root row for the hierarchy and an ORDER BY clause 
using the SIBLINGS keyword to preserve ordering within the hierarchy: 


SELECT last_name, employee_id, manager_id, LEVEL 
FROM employees 
START WITH employee_id = 100 
CONNECT BY PRIOR employee_id = manager_id 


ORDER SIBLINGS BY last_name; 


LAST_NAME EMPLOYEE _IDMANAGER ID LEVEL 
King 100 1 
Cambrault 148 100 2 
Bates 172 148 3 
Bloom 169 148 3 
Fox 170 148 3 
Kumar 173 148 3 
Ozer 168 148 3 
Smith 171 148 3 
De Haan 102 100 2 
Hunold 103 102 3 
Austin 105 103 4 
Ernst 104 103 4 
Lorentz 107 103 4 
Pataballa 106 103 4 
Errazuriz 147 100 2 
Ande 166 147 3 
Banda 167 147 3 


In the hr.employees table, the employee Steven King is the head of the company and has no manager. Among his 
employees is John Russell, who is the manager of department 80. If you update the employees table to set Russell 
as King's manager, you create a loop in the data: 


UPDATE employees SET manager_id = 145 
WHERE employee_id = 100; 


SELECT last_name "Employee", 
LEVEL, SYS_CONNECT_BY_PATH(last_name, '/') "Path" 
FROM employees 
WHERE level <= 3 AND department_id = 80 
START WITH last_name = 'King' 
CONNECT BY PRIOR employee_id = manager_id AND LEVEL <= 4; 


ERROR: 
ORA-01436: CONNECT BY loop in user data 


The NOCYCLE parameter in the CONNECT BY condition causes Oracle to return the rows in spite of the loop. 
The CONNECT_BY_ISCYCLE pseudocolumn shows you which rows contain the cycle: 


SELECT last_name "Employee", CONNECT_BY_ISCYCLE "Cycle", 
LEVEL, SYS_CONNECT_BY_PATH(last_name, ‘/') "Path" 
FROM employees 
WHERE level <= 3 AND department_id = 80 
START WITH last_name = 'King' 
CONNECT BY NOCYCLE PRIOR employee_id = manager_id AND LEVEL <= 4 
ORDER BY "Employee", "Cycle", LEVEL, "Path"; 


Employee Cycle LEVEL Path 


Abel 0 3 /King/Zlotkey/Abel 


Ande 0 3 /King/Errazuriz/Ande 
Banda 0 3 /King/Errazuriz/Banda 
Bates 0 3 /King/Cambrault/Bates 
Bernstein 0 3 /King/Russell/Bernstein 
Bloom 0 3 /King/Cambrault/Bloom 
Cambrault 0 2 /King/Cambrault 
Cambrault 0 3 /King/Russell/Cambrault 
Doran 0 3 /King/Partners/Doran 
Errazuriz 0 2 /King/Errazuriz 

Fox 0 3 /King/Cambrault/Fox 


CONNECT_BY_ISLEAF Example 


The following statement shows how you can use a hierarchical query to turn the values in a column into a comma- 
delimited list: 


SELECT LTRIM(SYS_CONNECT_BY_PATH (warehouse_id,','),',') FROM 
(SELECT ROWNUM r, warehouse_id FROM warehouses) 
WHERE CONNECT_BY_ISLEAF = 1 
START WITH r= 1 
CONNECT BY r= PRIORr+1 
ORDER BY warehouse_id; 


LTRIM(SYS_CONNECT_BY_PATH(WAREHOUSE_ID,',’),',') 


1,2,3,4,5,6,7,8,9 


CONNECT_BY_ROOT Examples 


The following example returns the last name of each employee in department 110, each manager at the highest 
level above that employee in the hierarchy, the number of levels between manager and employee, and the path 
between the two: 


SELECT last_name "Employee", CONNECT_BY_ROOT last_name "Manager", 
LEVEL-1 "Pathlen", SYS_CONNECT_BY_PATH(last_name, '/') "Path" 
FROM employees 
WHERE LEVEL > 1 and department_id = 110 
CONNECT BY PRIOR employee_id = manager_id 
ORDER BY "Employee", "Manager", "Pathlen", "Path"; 


Employee Manager Pathlen Path 

Gietz Higgins 1 /Higgins/Gietz 

Gietz King 3 /King/Kochhar/Higgins/Gietz 
Gietz Kochhar 2 /Kochhar/Higgins/Gietz 
Higgins King 2 /King/Kochhar/Higgins 
Higgins Kochhar 1 /Kochhar/Higgins 


The following example uses a GROUP BY clause to return the total salary of each employee in department 110 
and all employees above that employee in the hierarchy: 


SELECT name, SUM(salary) "Total_Salary" FROM ( 


SELECT CONNECT_BY_ROOT last_name as name, Salary 
FROM employees 
WHERE department_id = 110 
CONNECT BY PRIOR employee_id = manager_id) 
GROUP BY name 

ORDER BY name, "Total_Salary"; 


NAME Total_Salary 
Gietz 8300 
Higgins 20300 
King 20300 
Kochhar 20300 


The UNION [ALL], INTERSECT, MINUS Operators 


You can combine multiple queries using the set operators UNION, UNION ALL, INTERSECT, and MINUS. All 
set operators have equal precedence. If a SQL statement contains multiple set operators, then Oracle Database 
evaluates them from the left to right unless parentheses explicitly specify another order. 


The corresponding expressions in the select lists of the component queries of a compound query must match in 
number and must be in the same data type group (such as numeric or character). 


If component queries select character data, then the data type of the return values are determined as follows: 


If both queries select values of data type CHAR of equal length, then the returned values have data 
type CHAR of that length. If the queries select values of CHAR with different lengths, then the returned 
value is VARCHAR2 with the length of the larger CHAR value. 


- If either or both of the queries select values of data type VARCHAR2, then the returned values have data 
type VARCHAR2. 


If component queries select numeric data, then the data type of the return values is determined by numeric 
precedence: 


If any query selects values of type BINARY_DOUBLE, then the returned values have data 
type BINARY_DOUBLE. 


- If no query selects values of type BINARY_DOUBLE but any query selects values of 
type BINARY_FLOAT, then the returned values have data type BINARY_FLOAT. 


If all queries select values of type NUMBER, then the returned values have data type NUMBER. 


In queries using set operators, Oracle does not perform implicit conversion across data type groups. Therefore, if 
the corresponding expressions of component queries resolve to both character data and numeric data, Oracle 
returns an error. 


Examples 


The following query is valid: 


SELECT 3 FROM DUAL 
INTERSECT 
SELECT 3f FROM DUAL; 


This is implicitly converted to the following compound query: 


SELECT TO_BINARY_FLOAT(3) FROM DUAL 


INTERSECT 
SELECT 3f FROM DUAL; 


The following query returns an error: 


SELECT '3' FROM DUAL 
INTERSECT 
SELECT 3f FROM DUAL; 


Restrictions on the Set Operators 
The set operators are subject to the following restrictions: 


- The set operators are not valid on columns of type BLOB, CLOB, BFILE, VARRAY, or nested table. 
The UNION, INTERSECT, and MINUS operators are not valid on LONG columns. 


- Ifthe select list preceding the set operator contains an expression, then you must provide a column alias 
for the expression in order to refer to it in the order_by_clause . 


You cannot also specify the for_update_clause with the set operators. 
You cannot specify the order_by_clause in the subquery of these operators. 
- You cannot use these operators in SELECT statements containing TABLE collection expressions. 
UNION Example 


The following statement combines the results of two queries with the UNION operator, which eliminates duplicate 
selected rows. This statement shows that you must match data type (using the TO_CHAR function) when columns 
do not exist in one or the other table: 


SELECT location_id, department_name "Department", 
TO_CHAR(NULL) "Warehouse" FROM departments 
UNION 
SELECT location_id, TO_CHAR(NULL) "Department", warehouse_name 
FROM warehouses; 


LOCATION_ID Department Warehouse 
1400 IT 
1400 Southlake, Texas 
1500 Shipping 
1500 San Francisco 
1600 New Jersey 
1700 Accounting 
1700 Administration 
1700 Benefits 
1700 Construction 
1700 Contracting 
1700 Control And Credit 


UNION ALL Example 


The UNION operator returns only distinct rows that appear in either result, while the UNION ALL operator returns 
all rows. The UNION ALL operator does not eliminate duplicate selected rows: 


SELECT product_id FROM order_items 


UNION 
SELECT product_id FROM inventories 
ORDER BY product_id; 


SELECT location_id FROM locations 
UNION ALL 

SELECT location_id FROM departments 
ORDER BY location_id; 


A location_id value that appears multiple times in either or both queries (such as '1700') is returned only once by 
the UNION operator, but multiple times by the UNION ALL operator. 


INTERSECT Example 


The following statement combines the results with the INTERSECT operator, which returns only those unique 
rows returned by both queries: 


SELECT product_id FROM inventories 
INTERSECT 

SELECT product_id FROM order_items 
ORDER BY product_id; 


MINUS Example 


The following statement combines results with the MINUS operator, which returns only unique rows returned by 
the first query but not by the second: 


SELECT product_id FROM inventories 
MINUS 

SELECT product_id FROM order_items 
ORDER BY product_id; 


Sorting Query Results 


Use the ORDER BY clause to order the rows selected by a query. Sorting by position is useful in the following 
cases: 


- To order by a lengthy select list expression, you can specify its position in the ORDER BY clause rather 
than duplicate the entire expression. 


For compound queries containing set operators UNION, INTERSECT, MINUS, or UNION ALL, 

the ORDER BY clause must specify positions or aliases rather than explicit expressions. Also, 

the ORDER BY clause can appear only in the last component query. The ORDER BY clause orders all 
rows returned by the entire compound query. 


The mechanism by which Oracle Database sorts character values for the ORDER BY clause, also known as the 
collation, is specified by the NLS_SORT session parameter. If this parameter is not set, then its default is derived 
from the NLS_LANGUAGE session parameter. You can change the collation dynamically using 

the ALTER SESSION SET NLS_SORT statement. You can also apply a specific collation by including the 
character expressions to be sorted as arguments to the NLSSORT function, with the collation specified in the 
second parameter. 


When character values are compared linguistically for the ORDER BY clause, they are first transformed to 
collation keys and then compared like RAW values. The collation keys are generated either explicitly as specified 
in NLSSORT or implicitly using the same method that NLSSORT uses. As a result of these restrictions, two values 
may compare as linguistically equal if they do not differ in the prefix that was used to produce the collation key, 
even if they differ in the rest of the value. 


Joins 


A join is a query that combines rows from two or more tables, views, or materialized views. Oracle Database 
performs a join whenever multiple tables appear in the FROM clause of the query. The select list of the query can 
select any columns from any of these tables. If any two of these tables have a column name in common, then you 
must qualify all references to these columns throughout the query with table names to avoid ambiguity. 


Join Conditions 


Most join queries contain at least one join condition , either in the FROM clause or in the WHERE clause. The 
join condition compares two columns, each from a different table. To execute a join, Oracle Database combines 
pairs of rows, each containing one row from each table, for which the join condition evaluates to TRUE. The 
columns in the join conditions need not also appear in the select list. 


To execute a join of three or more tables, Oracle first joins two of the tables based on the join conditions 
comparing their columns and then joins the result to another table based on join conditions containing columns of 
the joined tables and the new table. Oracle continues this process until all tables are joined into the result. The 
optimizer determines the order in which Oracle joins tables based on the join conditions, indexes on the tables, 
and, any available statistics for the tables. 


A WHERE clause that contains a join condition can also contain other conditions that refer to columns of only one 
table. These conditions can further restrict the rows returned by the join query. 


Equijoins 

An equijoin is a join with a join condition containing an equality operator. An equijoin combines rows that have 
equivalent values for the specified columns. Depending on the internal algorithm the optimizer chooses to execute 
the join, the total size of the columns in the equijoin condition in a single table may be limited to the size of a data 


block minus some overhead. The size of a data block is specified by the initialization 
parameter DB_BLOCK_SIZE. 


Band Joins 


A band join is a special type of nonequijoin in which key values in one data set must fall within the specified 
range (“band”) of the second data set. The same table can serve as both the first and second data sets. 


Self Joins 


A self join is a join of a table to itself. This table appears twice in the FROM clause and is followed by table 
aliases that qualify column names in the join condition. To perform a self join, Oracle Database combines and 
returns rows of the table that satisfy the join condition. 


Cartesian Products 


If two tables in a join query have no join condition, then Oracle Database returns their Cartesian product . Oracle 
combines each row of one table with each row of the other. A Cartesian product always generates many rows and 
is rarely useful. For example, the Cartesian product of two tables, each with 100 rows, has 10,000 rows. Always 
include a join condition unless you specifically need a Cartesian product. If a query joins three or more tables and 
you do not specify a join condition for a specific pair, then the optimizer may choose a join order that avoids 
producing an intermediate Cartesian product. 


Inner Joins 


An inner join (sometimes called a simple join ) is a join of two or more tables that returns only those rows that 
satisfy the join condition. 


Outer Joins 


An outer join extends the result of a simple join. An outer join returns all rows that satisfy the join condition and 
also returns some or all of those rows from one table for which no rows from the other satisfy the join condition. 


To write a query that performs an outer join of tables A and B and returns all rows from A (a left outer 
join ), use the LEFT [OUTER] JOIN syntax in the FROM clause, or apply the outer join operator (+) to all 
columns of B in the join condition in the WHERE clause. For all rows in A that have no matching rows in 
B, Oracle Database returns null for any select list expressions containing columns of B. 


- To write a query that performs an outer join of tables A and B and returns all rows from B (a right outer 
join ), use the RIGHT [OUTER] JOIN syntax in the FROM clause, or apply the outer join operator (+) to 
all columns of A in the join condition in the WHERE clause. For all rows in B that have no matching rows 
in A, Oracle returns null for any select list expressions containing columns of A. 


To write a query that performs an outer join and returns all rows from A and B, extended with nulls if they 
do not satisfy the join condition (a full outer join ), use the FULL [OUTER] JOIN syntax in 
the FROM clause. 


You cannot compare a column with a subquery in the WHERE clause of any outer join, regardless which form you 
specify. 


You can use outer joins to fill gaps in sparse data. Such a join is called a partitioned outer join and is formed 
using the query_partition_clause of the join_clause syntax. Sparse data is data that does not have rows for all 
possible values of a dimension such as time or department. For example, tables of sales data typically do not have 
rows for products that had no sales on a given date. Filling data gaps is useful in situations where data sparsity 
complicates analytic computation or where some data might be missed if the sparse data is queried directly. 


Oracle recommends that you use the FROM clause OUTER JOIN syntax rather than the Oracle join operator. 
Outer join queries that use the Oracle join operator (+) are subject to the following rules and restrictions, which do 
not apply to the FROM clause OUTER JOIN syntax: 


You cannot specify the (+) operator in a query block that also contains FROM clause join syntax. 


- The (+) operator can appear only in the WHERE clause or, in the context of left-correlation (when 
specifying the TABLE clause) in the FROM clause, and can be applied only to a column of a table or view. 


If A and B are joined by multiple join conditions, then you must use the (+) operator in all of these 
conditions. If you do not, then Oracle Database will return only the rows resulting from a simple join, but 
without a warning or error to advise you that you do not have the results of an outer join. 


- The (+) operator does not produce an outer join if you specify one table in the outer query and the other 
table in an inner query. 


You cannot use the (+) operator to outer-join a table to itself, although self joins are valid. For example, 
the following statement is not valid: 


-- The following statement is not valid: 
SELECT employee_id, manager_id 
FROM employees 
WHERE employees.manager_id(+) = employees.employee_id; 


However, the following self join is valid: 


SELECT e1.employee_id, e1.manager_id, e2.employee_id 
FROM employees e1, employees e2 
WHERE el.manager_id(+) = e2.employee_id 
ORDER BY el.employee_id, e1.manager_id, e2.employee_id; 


The (+) operator can be applied only to a column, not to an arbitrary expression. However, an arbitrary 
expression can contain one or more columns marked with the (+) operator. 


- A WHERE condition containing the (+) operator cannot be combined with another condition using 
the OR logical operator. 


A WHERE condition cannot use the IN comparison condition to compare a column marked with the (+) 
operator with an expression. 


If the WHERE clause contains a condition that compares a column from table B with a constant, then the (+) 
operator must be applied to the column so that Oracle returns the rows from table A for which it has generated 
nulls for this column. Otherwise Oracle returns only the results of a simple join. 


In previous releases of Oracle Database, in a query that performed outer joins of more than two pairs of tables, a 
single table could be the null-generated table for only one other table. Beginning with Oracle Database 12 c , a 
single table can be the null-generated table for multiple tables. For example, the following statement is allowed in 
Oracle Database 12 c : 


SELECT * FROM A, B, D 
WHERE A.c1 = B.c2(+) and D.c3 = B.c4(+); 


In this example, B, the null-generated table, is outer-joined to two tables, A and D. 
Antijoins 


An antijoin returns rows from the left side of the predicate for which there are no corresponding rows on the right 
side of the predicate. It returns rows that fail to match (NOT IN) the subquery on the right side. 


Semijoins 


A semijoin returns rows that match an EXISTS subquery without duplicating rows from the left side of the 
predicate when multiple rows on the right side satisfy the criteria of the subquery. 


Semijoin and antijoin transformation cannot be done if the subquery is on an OR branch of the WHERE clause. 


Using Subqueries 


A subquery answers multiple-part questions. For example, to determine who works in Taylor's department, you 
can first use a subquery to determine the department in which Taylor works. You can then answer the original 
question with the parent SELECT statement. A subquery in the FROM clause of a SELECT statement is also 
called an inline view . you can nest any number of subqueries in an inline view. A subquery in the WHERE clause 
of a SELECT statement is also called a nested subquery . You can nest up to 255 levels of subqueries in the a 
nested subquery. 


A subquery can contain another subquery. Oracle Database imposes no limit on the number of subquery levels in 
the FROM clause of the top-level query. You can nest up to 255 levels of subqueries in the WHERE clause. 


If columns in a subquery have the same name as columns in the containing statement, then you must prefix any 
reference to the column of the table from the containing statement with the table name or alias. To make your 
statements easier to read, always qualify the columns in a subquery with the name or alias of the table, view, or 
materialized view. 


Oracle performs a correlated subquery when a nested subquery references a column from a table referred to a 
parent statement one or more levels above the subquery or nested subquery. The parent statement can be 

a SELECT, UPDATE, or DELETE statement in which the subquery is nested. A correlated subquery conceptually 
is evaluated once for each row processed by the parent statement. However, the optimizer may choose to rewrite 
the query as a join or use some other technique to formulate a query that is semantically equivalent. Oracle 
resolves unqualified columns in the subquery by looking in the tables named in the subquery and then in the tables 
named in the parent statement. 


A correlated subquery answers a multiple-part question whose answer depends on the value in each row processed 
by the parent statement. For example, you can use a correlated subquery to determine which employees earn more 
than the average salaries for their departments. In this case, the correlated subquery specifically computes the 
average salary for each department. 


Use subqueries for the following purposes: 


- To define the set of rows to be inserted into the target table of an INSERT or CREATE TABLE statement 


To define the set of rows to be included in a view or materialized view in 
a CREATE VIEW or CREATE MATERIALIZED VIEW statement 


- To define one or more values to be assigned to existing rows in an UPDATE statement 


To provide values for conditions in a WHERE clause, HAVING clause, or START WITH clause 
of SELECT, UPDATE, and DELETE statements 


To define a table to be operated on by a containing query 


You do this by placing the subquery in the FROM clause of the containing query as you would a table 
name. You may use subqueries in place of tables in this way as well in INSERT, UPDATE, 
and DELETE statements. 


Subqueries so used can employ correlation variables, both defined within the subquery itself and those 
defined in query blocks containing the subquery. 


Scalar subqueries, which return a single column value from a single row, are a valid form of expression. 
You can use scalar subquery expressions in most of the places where expr is called for in syntax. 


Unnesting of Nested Subqueries 


Subqueries are nested when they appear in the WHERE clause of the parent statement. When Oracle Database 
evaluates a statement with a nested subquery, it must evaluate the subquery portion multiple times and may 
overlook some efficient access paths or joins. 


Subquery unnesting unnests and merges the body of the subquery into the body of the statement that contains it, 
allowing the optimizer to consider them together when evaluating access paths and joins. The optimizer can unnest 
most subqueries, with some exceptions. Those exceptions include hierarchical subqueries and subqueries that 
contain a ROWNUM pseudocolumn, one of the set operators, a nested aggregate function, or a correlated 
reference to a query block that is not the immediate outer query block of the subquery. 


Assuming no restrictions exist, the optimizer automatically unnests some (but not all) of the following nested 
subqueries: 


Uncorrelated IN subqueries 


- IN and EXISTS correlated subqueries, as long as they do not contain aggregate functions or 
a GROUP BY clause 


You can enable extended subquery unnesting by instructing the optimizer to unnest additional types of 
subqueries: 


You can unnest an uncorrelated NOT IN subquery by specifying the HASH_AJ or MERGE_AJ hint in the 
subquery. 


You can unnest other subqueries by specifying the UNNEST hint in the subquery. 
Selecting from the DUAL Table 


DUAL is a table automatically created by Oracle Database along with the data dictionary. DUAL is in the schema 
of the user SYS but is accessible by the name DUAL to all users. It has one column, DUMMY, defined to 

be VARCHAR2(1), and contains one row with a value X. Selecting from the DUAL table is useful for computing a 
constant expression with the SELECT statement. Because DUAL has only one row, the constant is returned only 
once. Alternatively, you can select a constant, pseudocolumn, or expression from any table, but the value will be 
returned as many times as there are rows in the table. 


Distributed Queries 


The Oracle distributed database management system architecture lets you access data in remote databases using 
Oracle Net and an Oracle Database server. You can identify a remote table, view, or materialized view by 
appending @ dblink to the end of its name. The dblink must be a complete or partial name for a database link to 
the database containing the remote table, view, or materialized view. 


Types of SQL Statements 


The lists in the following sections provide a functional summary of SQL 
statements and are divided into these categories: 


- Data Definition Language (DDL) Statements 
Data Manipulation Language (DML) Statements 
- Transaction Control Statements 
Session Control Statements 
System Control Statement 
Embedded SQL Statements 


Data Definition Language (DDL) Statements 
Data definition language (DDL) statements let you to perform these tasks: 


Create, alter, and drop schema objects 
Grant and revoke privileges and roles 
- Analyze information on a table, index, or cluster 
Establish auditing options 
- Add comments to the data dictionary 
The CREATE, ALTER, and DROP commands require exclusive access to 


the specified object. For example, an ALTER TABLE statement fails if 
another user has an open transaction on the specified table. 


The GRANT, REVOKE, ANALYZE, AUDIT, and COMMENT commands 
do not require exclusive access to the specified object. For example, you 
can analyze a table while other users are updating the table. 


Oracle Database implicitly commits the current transaction before and after 
every DDL statement. 


A DDL statement is either blocking or nonblocking, and both types of DDL 
statements require exclusive locks on internal structures. 


The DDL statements are: 
- CREATE... (All statements beginning with CREATE) 


ALTER ... (All statements beginning with ALTER, 

except ALTER SESSION and ALTER SYSTEM) 
- DROP... (All statements beginning with DROP) 
- GRANT 

PURGE 

RENAME 

REVOKE 

TRUNCATE 

COMMENT 


Data Manipulation Language (DML) Statements 


Data manipulation language (DML) statements access and manipulate data 
in existing schema objects. These statements do not implicitly commit the 
current transaction. The data manipulation language statements are: 


« INSERT 

© SELECT 
UPDATE 
DELETE 
LOCK TABLE 
MERGE 

«e CALL 

» EXPLAIN PLAN 


The SELECT statement is a limited form of DML statement in that it can 
only access data in the database. It cannot manipulate data stored in the 
database, although it can manipulate the accessed data before returning the 
results of the query. 


The SELECT statement is supported in PL/SQL only when executed 
dynamically. However, you can use the similar PL/SQL 

statement SELECT INTO in PL/SQL code, and you do not have to execute 
it dynamically. The CALL and EXPLAIN PLAN statements are supported 
in PL/SQL only when executed dynamically. All other DML statements are 
fully supported in PL/SQL. 


Transaction Control Statements 


Transaction control statements manage changes made by DML statements. 
The transaction control statements are: 


«e COMMIT 

«e ROLLBACK 

e SAVEPOINT 

«e SET TRANSACTION 
SET CONSTRAINT 


All transaction control statements, except certain forms of 
the COMMIT and ROLLBACK commands, are supported in PL/SQL. 


Session Control Statements 


Session control statements dynamically manage the properties of a user 
session. These statements do not implicitly commit the current transaction. 


PL/SQL does not support session control statements. The session control 
statements are: 


ALTER SESSION 
SET ROLE 


System Control Statement 


The single system control statement, ALTER SYSTEM, dynamically 
manages the properties of an Oracle Database instance. This statement does 
not implicitly commit the current transaction and is not supported in 
PL/SQL. 


Data Definition Language (DDL) Statements 
Data definition language (DDL) statements let you to perform these tasks: 


- Create, alter, and drop schema objects 
Grant and revoke privileges and roles 

- Analyze information on a table, index, or cluster 
Establish auditing options 
Add comments to the data dictionary 


The CREATE, ALTER, and DROP commands require exclusive access to 
the specified object. For example, an ALTER TABLE statement fails if 
another user has an open transaction on the specified table. 


TABLE 


Tables are the basic unit of data storage in an Oracle Database. Data is 
stored in rows and columns. You define a table with a table name, such as 
employees, and a set of columns. You give each column a column name, 
such as employee_id, last_name, and job_id; a datatype, such as 
VARCHAR2, DATE, or NUMBER; and a width. The width can be 
predetermined by the datatype, as in DATE. If columns are of the 
NUMBER datatype, define precision and scale instead of width. A row is a 
collection of column information corresponding to a single record. 


You can specify rules for each column of a table. These rules are called 
integrity constraints. One example is a NOT NULL integrity constraint. 
This constraint forces the column to contain a value in every row. 


You can also invoke transparent data encryption to encrypt data before 
storing it in the datafile. Then, if users attempt to circumvent the database 
access control mechanisms by looking inside datafiles directly with 
operating system tools, encryption prevents these users from viewing 
sensitive data. 


After you create a table, insert rows of data using SQL statements. Table 
data can then be queried, deleted, or updated using SQL. 


CREATE TABLE 


Use the CREATE TABLE statement to create one of the following types of 
tables: 


A relational table , which is the basic structure to hold user data. 


- An object table , which is a table that uses an object type for a 
column definition. An object table is explicitly defined to hold object 
instances of a particular type. 


You can also create an object type and then use it in a column when creating 
a relational table. 


Tables are created with no data unless a subquery is specified. You can add 
rows to a table with the INSERT statement. After creating a table, you can 
define additional columns, partitions, and integrity constraints with 

the ADD clause of the ALTER TABLE statement. You can change the 
definition of an existing column or partition with the MODIFY clause of 
the ALTER TABLE statement. 


To create a relational table in your own schema, you must have 

the CREATE TABLE system privilege. To create a table in another user's 
schema, you must have the CREATE ANY TABLE system privilege. Also, 
the owner of the schema to contain the table must have either space quota 
on the tablespace to contain the table or 

the UNLIMITED TABLESPACE system privilege. 


In addition to these table privileges, to create an object table or a relational 
table with an object type column, the owner of the table must have 

the EXECUTE object privilege in order to access all types referenced by 
the table, or you must have the EXECUTE ANY TYPE system privilege. 
These privileges must be granted explicitly and not acquired through a role. 


Additionally, if the table owner intends to grant access to the table to other 
users, then the owner must have been granted the EXECUTE object 
privilege on the referenced types WITH GRANT OPTION, or have 

the EXECUTE ANY TYPE system privilege WITH ADMIN OPTION. 
Without these privileges, the table owner has insufficient privileges to grant 
access to the table to other users. 


To enable a unique or primary key constraint, you must have the privileges 
necessary to create an index on the table. You need these privileges because 
Oracle Database creates an index on the columns of the unique or primary 
key in the schema containing the table. 


To specify an edition in the evaluation_edition_clause or the 
unusable_editions_clause , you must have the USE privilege on the edition. 


To specify the zonemap_clause , you must have the permissions necessary 
to create a zone map. 


To create an external table , you must have the required read and write 
operating system privileges on the appropriate operating system directories. 
You must have the READ object privilege on the database directory object 
corresponding to the operating system directory in which the external data 
resides. You must also have the WRITE object privilege on the database 
directory in which the files will reside if you specify a log file or bad file in 
the opaque_format_spec or if you unload data into an external table from a 
database table by specifying the AS subquery clause. 


To create an XMLType table in a different database schema from your 
own, you must have not only privilege CREATE ANY TABLE but also 
privilege CREATE ANY INDEX. This is because a unique index is created 
on column OBJECT_ID when you create the table. 

Column OBJECT_ID stores a system-generated object identifier. 


GLOBAL TEMPORARY 


Specify GLOBAL TEMPORARY to create a temporary table, whose 
definition is visible to all sessions with appropriate privileges. The data 
in a temporary table is visible only to the session that inserts the data into 
the table. 


When you first create a temporary table, its metadata is stored in the data 
dictionary, but no space is allocated for table data. Space is allocated for the 
table segment at the time of the first DML operation on the table. The 
temporary table definition persists in the same way as the definitions of 
regular tables, but the table segment and any data the table contains are 
either session-specific or transaction-specific data. 


You can perform DDL operations (such 
as ALTER TABLE, DROP TABLE, CREATE INDEX) on a temporary table 


only when no session is bound to it. A session becomes bound to a 
temporary table with an INSERT operation on the table. A session becomes 
unbound to a temporary table with a TRUNCATE statement or at session 
termination, or, for a transaction-specific temporary table, by issuing 

a COMMIT or ROLLBACK statement. 


PRIVATE TEMPORARY 
Specify PRIVATE TEMPORARY to create a private temporary table. 


A private temporary table differs from a temporary table in that its 
definition and data are visible only within the session that created it. 
Use the ON COMMIT clause to define the scope of a private temporary 
table: either transaction or session . The ON COMMIT clause used with 
the keywords DROP DEFINITION creates a transaction-specific table 
whose data and definition are dropped when the transaction commits. This 
is the default behavior. The ON COMMIT clause used with 

keywords PRESERVE DEFINITION creates a session-specific table whose 
definition is preserved when the transaction commits. See here for usage 
details of theON COMMIT clause. 


Three DDL statements are supported for private temporary 
tables: CREATE, DROP, and TRUNCATE. 


SHARDED 
Specify SHARDED to create a sharded table. 


This clause is valid only if you are using Oracle Sharding, which is a data 
tier architecture in which data is horizontally partitioned across independent 
databases. Each database in such configuration is called a shard. All of the 
shards together make up a single logical database, which is referred to as a 
sharded database (SDB). Horizontal partitioning involves splitting a table 
across shards so that each shard contains the table with the same columns 
but a different subset of rows. A table split up in this manner is called a 
sharded table. 


When you create a sharded table, you must specify a tablespace set in 
which to create the table. There is no default tablespace set for sharded 
tables. 


Oracle Sharding is based on the Oracle Partitioning feature. Therefore, a 
sharded table must be a partitioned or composite-partitioned table. When 
creating a sharded table, you must specify one of the 
table_partitioning_clauses . 


DUPLICATED 


This clause is valid only if you are using Oracle Sharding. 
Specify DUPLICATED to create a duplicated table, which is duplicated on 
all shards. It can be a nonpartitioned table or partitioned table. 


Duplicated tables are not tied to any table family. 
Examples 
Creating Tables: General Examples 


This statement shows how the employees table owned by the sample human 
resources (hr) schema was created. A hypothetical name is given to the 
table and constraints so that you can duplicate this example in your test 
database: 


CREATE TABLE employees_demo 
(employee_id NUMBER(6) 
,first_name VARCHAR2(20) 
,last_name VARCHAR2(25) 
CONSTRAINT emp_last_name_nn_demo NOT NULL 
, email VARCHAR2(25) 
CONSTRAINT emp_email_nn_demo NOT NULL 
, phone_number VARCHAR2(20) 
, hire_date DATE DEFAULT SYSDATE 
CONSTRAINT emp_hire_date_nn_demo NOT NULL 
, Job_id VARCHAR2(10) 
CONSTRAINT emp_job_nn_demo NOT NULL 
, salary NUMBER(8,2) 
CONSTRAINT  emp_salary_nn_demo NOT NULL 
, commission_pct NUMBER(2,2) 
, manager_id NUMBER(6) 
, department_id NUMBER(4) 
, dn VARCHAR2(300) 


, CONSTRAINT — emp_salary_min_demo 
CHECK (salary > 0) 

, CONSTRAINT — emp_email_uk_demo 
UNIQUE (email) 

); 


This table contains twelve columns. The employee_id column is of data 
type NUMBER. The hire_date column is of data type DATE and has a 
default value of SYSDATE. The last_name column is of 

type VARCHAR2 and has a NOT NULL constraint, and so on. 


Creating a Table: Storage Example 


To define the same employees_demo table in the example tablespace with a 
small storage capacity, issue the following statement: 


CREATE TABLE employees_demo 

(employee_id NUMBER(6) 
,first_name VARCHAR2(20) 
,last_name VARCHAR2(25) 

CONSTRAINT emp_last_name_nn_demo NOT NULL 
, email VARCHAR2(25) 

CONSTRAINT emp_email_nn_demo NOT NULL 
, phone_number VARCHAR2(20) 
, hire_date DATE DEFAULT SYSDATE 

CONSTRAINT emp_hire_date_nn_demo NOT NULL 
, Job_id VARCHAR2(10) 

CONSTRAINT emp_job_nn_demo NOT NULL 
, salary NUMBER(8,2) 
CONSTRAINT = emp_salary_nn_demo NOT NULL 
, commission_pct NUMBER(2,2) 
, manager_id NUMBER(6) 
, department_id NUMBER(4) 
, dn VARCHAR2(300) 
, CONSTRAINT — emp_salary_min_demo 
CHECK (salary > 0) 
, CONSTRAINT — emp_email_uk_demo 
UNIQUE (email) 


) 
TABLESPACE example 


STORAGE (INITIAL 8M); 


Creating a Table with a DEFAULT ON NULL Column Value: Example 


The following statement creates a table myemp, which can be used to store 
employee data. The department_id column is defined with 

a DEFAULT ON NULL column value of 50. Therefore, if a 

subsequent INSERT statement attempts to assign a NULL value 

to department_id, then the value of 50 will be assigned instead. 


CREATE TABLE myemp (employee_id number, last_name 
varchar2(25), 

department_id NUMBER DEFAULT ON NULL 50 NOT 
NULL); 


In the employees table, employee_id 178 has a NULL value 
for department_id: 


SELECT employee_id, last_name, department_id 
FROM employees 
WHERE department_id IS NULL; 


EMPLOYEE_ID LAST_NAME DEPARTMENT_ID 


178 Grant 


Populate the myemp table with the employee_id, last_name, 
and department_id column data from the employees table: 


INSERT INTO myemp (employee_id, last_name, department_id) 
(SELECT employee_id, last_name, department_id from employees); 


In the myemp table, employee_id 178 has a value of 50 for department_id: 


SELECT employee_id, last_name, department_id 
FROM myemp 
WHERE employee_id = 178; 


EMPLOYEE_ID LAST_NAME DEPARTMENT_ID 


178 Grant 50 


Creating a Table with an Identity Column: Examples 


The following statement creates a table t1 with an identity column id. The 
sequence generator will always assign increasing integer values to id, 
starting with 1. 


CREATE TABLE t1 (id NUMBER GENERATED AS IDENTITY); 


The following statement creates a table t2 with an identity column id. The 
sequence generator will, by default, assign increasing integer values to id in 
increments of 10 starting with 100. 


CREATE TABLE t2 (id NUMBER GENERATED BY DEFAULT AS 
IDENTITY (START WITH 100 INCREMENT BY 10)); 


Creating a Table: Temporary Table Example 


The following statement creates a temporary table today_sales for use by 
sales representatives in the sample database. Each sales representative 
session can store its own sales data for the day in the table. The temporary 
data is deleted at the end of the session. 


CREATE GLOBAL TEMPORARY TABLE today_sales 
ON COMMIT PRESERVE ROWS 
AS SELECT * FROM orders WHERE order_date = SYSDATE; 


Creating a Table with Deferred Segment Creation: Example 


The following statement creates a table with deferred segment creation. 
Oracle Database will not create a segment for the data of this table until 
data is inserted into the table: 


CREATE TABLE later (coll NUMBER, col2 VARCHAR2(20)) 
SEGMENT CREATION DEFERRED; 


Substitutable Table and Column Examples 


The following statements create a type hierarchy, which can be used to 
create a substitutable table. Type employee_t inherits 

the name and ssn attributes from type person_t and in addition 

has department_id and salary attributes. Type part_time_emp_t inherits all 
of the attributes from employee_t and, through employee_t, those 

of person_t and in addition has a num_hrs attribute. 

Type part_time_emp_t is final by default, so no further subtypes can be 
created under it. 


CREATE TYPE person_t AS OBJECT (name VARCHAR2(100), ssn 
NUMBER) 

NOT FINAL; 
/ 


CREATE TYPE employee_t UNDER person_t 
(department_id NUMBER, salary NUMBER) NOT FINAL; 
/ 


CREATE TYPE part_time_emp_t UNDER employee_t (num_hrs 


NUMBER); 
/ 


The following statement creates a substitutable table from 
the person_t type: 


CREATE TABLE persons OF person_t; 


The following statement creates a table with a substitutable column of 
type person_t: 


CREATE TABLE books (title VARCHAR2(100), author person_t); 


When you insert into persons or books, you can specify values for the 
attributes of person_t or any of its subtypes. 


You can extract data from such tables using built-in functions and 
conditions. 


Creating a Table: Parallelism Examples 


The following statement creates a table using an optimum number of 
parallel execution servers to scan employees and to populate dept_80: 


CREATE TABLE dept_80 
PARALLEL 
AS SELECT * FROM employees 
WHERE department_id = 80; 


Using parallelism speeds up the creation of the table, because the database 
uses parallel execution servers to create the table. After the table is created, 
querying the table is also faster, because the same degree of parallelism is 
used to access the table. 


The following statement creates the same table serially. Subsequent DML 
and queries on the table will also be serially executed. 


CREATE TABLE dept_80 
AS SELECT * FROM employees 
WHERE department_id = 80; 


Creating a Table: ENABLE/DISABLE Examples 


The following statement shows how the sample table departments was 
created. The example defines a NOT NULL constraint, and places it 


in ENABLE VALIDATE state. A hypothetical name is given to the table so 
that you can duplicate this example in your test database: 


CREATE TABLE departments_demo 
( department_id NUMBER(4) 
, department_name VARCHAR2(30) 
CONSTRAINT dept_name_nn NOT NULL 
,manager_id NUMBER(6) 
, location id NUMBER(A4) 
, dn VARCHAR2(300) 


K 


The following statement creates the same departments_demo table but also 
defines a disabled primary key constraint: 


CREATE TABLE departments_demo 
( department_id NUMBER(4) PRIMARY KEY DISABLE 
, department_name VARCHAR2(30) 
CONSTRAINT dept_name_nn NOT NULL 
, manager_id NUMBER(6) 
, location id NUMBER(A4) 
, dn VARCHAR2(300) 


); 


Nested Table Example 


The following statement shows how the sample table pm.print_media was 
created with a nested table column ad_textdocs_ntab: 


CREATE TABLE print_media 
( product_id NUMBER(6) 
, ad_id NUMBER(6) 
,ad_composite BLOB 
, ad_sourcetext CLOB 
, ad_finaltext CLOB 
, ad_fltextn NCLOB 


, ad_textdocs_ntab textdoc_tab 

, ad_photo BLOB 

, ad_graphic BFILE 

, ad_header adheader_typ 

) NESTED TABLE ad_textdocs_ntab STORE AS 
textdocs_nestedtab; 


Creating a Table: Multilevel Collection Example 


The following example shows how an account manager might create a table 
of customers using two levels of nested tables: 


CREATE TYPE phone AS OBJECT (telephone NUMBER); 
/ 
CREATE TYPE phone_list AS TABLE OF phone; 
/ 
CREATE TYPE my_customers AS OBJECT ( 
cust_name VARCHAR2(25), 
phones phone_list); 
/ 
CREATE TYPE customer_list AS TABLE OF my_customers; 
/ 
CREATE TABLE business_contacts ( 
company_name VARCHAR2(25), 
company_reps customer _list) 
NESTED TABLE company_reps STORE AS outer_ntab 
(NESTED TABLE phones STORE AS inner_ntab); 


The following variation of this example shows how to use 
the COLUMN_VALUE keyword if the inner nested table has no column or 
attribute name: 


CREATE TYPE phone AS TABLE OF NUMBER; 
/ 
CREATE TYPE phone_list AS TABLE OF phone; 
/ 


CREATE TABLE my_customers ( 
name VARCHAR2(25), 
phone_numbers phone_list) 
NESTED TABLE phone_numbers STORE AS outer_ntab 
(NESTED TABLE COLUMN_VALUE STORE AS inner_ntab); 


Creating a Table: LOB Column Example 


The following statement is a variation of the statement that created 
the pm.print_media table with some added LOB storage characteristics: 


CREATE TABLE print_media_new 
( product_id NUMBER(6) 
, ad_id NUMBER(6) 
,ad_composite BLOB 
, ad_sourcetext CLOB 
, ad_finaltext CLOB 
, ad_fltextn NCLOB 
, ad_textdocs_ntab textdoc_tab 
, ad_photo BLOB 
, ad_graphic BFILE 
, ad_header adheader_typ 
) NESTED TABLE ad_textdocs_ntab STORE AS 
textdocs_nestedtab_new 
LOB (ad_sourcetext, ad_finaltext) STORE AS 
(TABLESPACE example 
STORAGE (INITIAL 6144) 
CHUNK 4000 
NOCACHE LOGGING); 


In the example, the database rounds the value of CHUNK up to 4096 (the 
nearest multiple of the block size of 2048). 


Index-Organized Table Example 


The following statement is a variation of the sample table hr.countries, 
which is index organized: 


CREATE TABLE countries_demo 
(country_id CHAR(2) 
CONSTRAINT country_id_nn_demo NOT NULL 
, country_name VARCHAR2(40) 
, currency_name VARCHAR2(25) 
, currency_symbol VARCHAR2(3) 
, region VARCHAR2(15) 
, CONSTRAINT  country_c_id_pk_demo 
PRIMARY KEY (country_id ) ) 
ORGANIZATION INDEX 
INCLUDING country_name 
PCTTHRESHOLD 2 
STORAGE 
(INITIAL 4K ) 
OVERFLOW 
STORAGE 
(INITIAL 4K ); 


External Table Example 


The following statement creates an external table that represents a subset of 
the sample table hr.departments. The TYPE clause specifies that the access 
driver type for the table is ORACLE_LOADER. 

The ACCESS PARAMETERS() clause specifies parameter values for 

the ORACLE_LOADER access driver. These parameters are shown in 
italics and form the opaque_format_spec . The syntax for 
opaque_format_spec depends on the access driver type and is outside the 
scope of this document. 


CREATE TABLE dept_external ( 
deptno NUMBER(6), 
dname VARCHAR2(20), 
loc VARCHAR2(25) 

) 

ORGANIZATION EXTERNAL 

(TYPE oracle_loader 


DEFAULT DIRECTORY admin 
ACCESS PARAMETERS 
( 
RECORDS DELIMITED BY newline 
BADFILE 'ulcase1.bad' 
DISCARDFILE 'ulcasel1.dis' 
LOGFILE 'ulcase1.log' 
SKIP 20 
FIELDS TERMINATED BY "," OPTIONALLY ENCLOSED BY '"" 


( 

deptno INTEGER EXTERNAL/(6), 
dname  CHAR(20), 

loc CHAR(25) 


) 


LOCATION (‘ulcase1.ctl'’) 


) 
REJECT LIMIT UNLIMITED; 


XMLType Examples 


This section contains brief examples of creating an XMLType table 
or XMLType column. For a more expanded version of these examples. 


XMLType Table Examples 


The following example creates a very simple XMLType table with one 
implicit binary XML column: 


CREATE TABLE xwarehouses OF XMLTYPE; 


The following example creates an XMLSchema-based table. The 
XMLSchema must already have been created: 


CREATE TABLE xwarehouses OF XMLTYPE 
XMLSCHEMA "http://www.example.com/xwarehouses.xsd" 
ELEMENT "Warehouse"; 


You can define constraints on an XMLSchema-based table, and you can 
also create indexes on XMLSchema-based tables, which greatly enhance 
subsequent queries. You can create object-relational views 

on XMLType tables, and you can create XMLType views on object- 
relational tables. 


XMLType Column Examples 


The following example creates a table with an XMLType column stored as 
a CLOB. This table does not require an XMLSchema, so the content 
structure is not predetermined: 


CREATE TABLE xwarehouses ( 
warehouse_id NUMBER, 
warehouse_spec XMLTYPE) 
XMLTYPE warehouse_spec STORE AS CLOB 
(TABLESPACE example 
STORAGE (INITIAL 6144) 
CHUNK 4000 
NOCACHE LOGGING); 


The following example creates a similar table, but stores XMLType data in 
an object relational XMLType column whose structure is determined by the 
specified schema: 


CREATE TABLE xwarehouses ( 
warehouse_id NUMBER, 
warehouse_spec XMLTYPE) 
XMLTYPE warehouse_spec STORE AS OBJECT RELATIONAL 
XMLSCHEMA "http://www.example.com/xwarehouses.xsd" 
ELEMENT "Warehouse"; 


The following example creates another similar table with 
an XMLType column stored as a SecureFiles CLOB. This table does not 
require an XMLSchema, so the content structure is not predetermined. 


SecureFiles LOBs require a tablespace with automatic segment-space 
management. 


CREATE TABLE xwarehouses ( 
warehouse_id NUMBER, 
warehouse_spec XMLTYPE) 
XMLTY PE warehouse_spec STORE AS SECUREFILE CLOB 
(TABLESPACE auto_seg_ts 
STORAGE (INITIAL 6144) 
CACHE); 


Partitioning Examples 
Range Partitioning Example 


The sales table in the sample schema sh is partitioned by range. The 
following example shows an abbreviated variation of the sales table. 
Constraints and storage elements have been omitted from the example. 


CREATE TABLE range_sales 
( prod_id NUMBER(6) 
, cust_id NUMBER 
, time_id DATE 
,channel_id CHAR(1) 
, promo_id NUMBER(6) 
, quantity_sold NUMBER(3) 
, amount_sold NUMBER(10,2) 
) 
PARTITION BY RANGE (time_id) 
(PARTITION SALES_Q1_1998 VALUES LESS THAN 
(TO_DATE('01-APR-1998',,DD-MON-YYYY’)), 
PARTITION SALES_Q2_1998 VALUES LESS THAN 
(TO_DATE('01-JUL-1998',,DD-MON-YYYY')), 
PARTITION SALES_Q3_1998 VALUES LESS THAN 
(TO_DATE('01-OCT-1998',,DD-MON-YYYY')), 
PARTITION SALES_Q4_1998 VALUES LESS THAN 
(TO_DATE('01-JAN-1999',,DD-MON-YYYY')), 


PARTITION SALES_Q1_1999 VALUES LESS THAN 
(TO_DATE('01-APR-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q2_1999 VALUES LESS THAN 
(TO_DATE('01-JUL-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q3_1999 VALUES LESS THAN 
(TO_DATE('01-OCT-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q4_1999 VALUES LESS THAN 
(TO_DATE('01-JAN-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q1_2000 VALUES LESS THAN 
(TO_DATE('01-APR-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q2_2000 VALUES LESS THAN 
(TO_DATE('01-JUL-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q3_ 2000 VALUES LESS THAN 
(TO_DATE('01-OCT-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q4_2000 VALUES LESS THAN 
(MAXVALUE)) 


3 


Range Partitioning Live SQL Example 


The following statement creates a table partitioned by range: 


CREATE TABLE empl_h 
( 
employee id NUMBER(6) PRIMARY KEY, 
firstname VARCHAR2(20), 
last name VARCHAR2(25), 
email VARCHAR2(25), 
phone_number VARCHAR2(20), 
hire_date DATE DEFAULT SYSDATE, 
job_id  VARCHAR2(10), 
salary NUMBER(8, 2), 
part_name VARCHAR2(25) 
) PARTITION BY RANGE (hire_date) ( 
PARTITION hire_q1 VALUES less than(to_date('01-APR-2014', 'DD- 
MON-YYYY’)), 


PARTITION hire_q2 VALUES less than(to_date('01-JUL-2014', 'DD- 
MON-YYYY’)), 
PARTITION hire_q3 VALUES less than(to_date('01-OCT-2014', 'DD- 
MON-YYYY’)), 
PARTITION hire_g4 VALUES less than(to_date('01-JAN-2015', 'DD- 
MON-YYYY’)) 


); 
The following statements insert rows into the partitions: 


INSERT INTO empl_h (employee_id, first_name, last_name, email, 
phone_number, hire_date, job_id, salary, Part_name) 

VALUES (1, ‘Jane’, 'Doe', 'example.com’, '415.555.0100', '10-Feb- 
2014’, '1001', 5001,'HIRE_Ql1'); 


INSERT INTO empl_h (employee_id, first_name, last_name, email, 
phone_number, hire_date, job_id, salary, Part_name) 

VALUES (2, ‘John’, 'Doe', 'example.net', '415.555.0101', '10-Apr- 
2014', '1002', 7001,'HIRE_Q2’'); 


INSERT INTO empl_h (employee_id, first_name, last_name, email, 
phone_number, hire_date, job_id, salary, Part_name) 

VALUES (3, ‘Isabelle’, ‘Owl, 'example.org', '415.555.0102', '10-Sep- 
2014’, '1003', 10001,'HIRE_Q3'); 


INSERT INTO empl_h (employee_id, first_name, last_name, email, 
phone_number, hire_date, job_id, salary, Part_name) 

VALUES (4, 'Smith', ‘Jones’, 'example.in', '415.555.0103', '10-Dec- 
2014’, '1004', 12001,'HIRE_Q4’); 


The following statements display the partition names using data dictionary 
tables: 


SELECT PARTTTION_NAME FROM USER_TAB_ PARTITIONS 
WHERE TABLE NAME ='EMPL_H;; 


PARTITION_NAME 
HIRE_Q1 
HIRE_Q2 
HIRE_Q3 
HIRE_Q4 


SELECT TABLE NAME, PARTTTIONING_TYPE, STATUS FROM 
USER_PART_TABLES WHERE TABLE NAME = 'EMPL_H’; 


TABLE NAME PARTITIONING_TYPE STATUS 


EMPL_H RANGE VALID 


The following statement creates a table named parts by selecting a 
particular column from the data dictionary table user_tab_partitions: 


CREATE TABLE parts (p_name) AS SELECT PARTITION_NAME 
FROM USER_TAB_PARTTTIONS WHERE TABLE NAME = 
'EMPL_H’; 


The following statement displays the table data: 


select * from parts; 


HIRE_Q1 
HIRE_Q2 
HIRE_Q3 
HIRE_Q4 


The following statement compares the columns from the two tables and 
displays the information based on the comparison: 


select E.HIRE_DATE,E.JOB_ID,P.p_name from empl_h E, parts P 
where E.Part_name = P.p_name; 


HIRE_DATE JOB_ID P_ NAME 
10-FEB-14 1001 HIRE_Q1 
10-APR-14 1002 HIRE Q2 
10-SEP-14 1003 HIRE_Q3 
10-DEC-14 1004 HIRE _Q4 


Interval Partitioning Example 


The following example creates a variation of the oe.customers table that is 
partitioned by interval on the credit_limit column. One range partition is 
created to establish the transition point. All of the original data in the table 
is within the bounds of the range partition. Then data is added that exceeds 
the range partition, and the database creates a new interval partition. 


CREATE TABLE customers_demo ( 
customer_id number(6), 
cust_first_name varchar2(20), 
cust_last_name varchar2(20), 
credit_limit number(9,2)) 
PARTITION BY RANGE (credit_limit) 
INTERVAL (1000) 
(PARTITION p1 VALUES LESS THAN (5001)); 


INSERT INTO customers_ demo 
(customer_id, cust_first_name, cust_last_name, credit_limit) 
(select customer_id, cust_first_name, cust_last_name, credit_limit 
from customers); 


Query the USER_TAB_PARTITIONS data dictionary view before the 
database creates the interval partition: 


SELECT partition_name, high_value FROM user_tab_partitions 
WHERE table_name = 'CUSTOMERS_DEMO'; 


PARTTTION_NAME HIGH_VALUE 


Insert data into the table that exceeds the high value of the range partition: 


INSERT INTO customers_ demo 
VALUES (699, ‘Fred’, 'Flintstone’, 5500); 


Query the USER_TAB_PARTITIONS view again after the insert to learn 
the system-generated name of the interval partition created to accommodate 
the inserted data. (The system-generated name will vary for each session.) 


SELECT partition_name, high_value FROM user_tab_partitions 
WHERE table_name = 'CUSTOMERS_DEMO' 
ORDER BY partition_name; 


PARTTTION_NAME HIGH_VALUE 
P1 5001 
SYS_P44 6001 


List Partitioning Example 


The following statement shows how the sample table oe.customers might 
have been created as a list-partitioned table. Some columns and all 
constraints of the sample table have been omitted in this example. 


CREATE TABLE list_customers 
( customer_id NUMBER(6) 
, cust_first_name VARCHAR2(20) 
, cust_last_name VARCHAR2(20) 


, cust_address CUST_ADDRESS_TYP 

, nls_territory VARCHAR2(30) 

, cust_email VARCHAR2(40)) 

PARTITION BY LIST (nls_territory) ( 

PARTITION asia VALUES ('CHINA', "THAILAND'), 

PARTITION europe VALUES (‘GERMANY ', 'ITALY’, 
‘SWITZERLAND’, 

PARTITION west VALUES (‘AMERICA’), 

PARTITION east VALUES (‘INDIA’), 

PARTITION rest VALUES (DEFAULT)); 


Partitioned Table with LOB Columns Example 


This statement creates a partitioned table print_media_demo with two 
partitions p1 and p2, and a number of LOB columns. The statement uses the 
sample table pm.print_media. 


CREATE TABLE print_media_demo 
( product_id NUMBER(6) 
, ad_id NUMBER(6) 
, ad_composite BLOB 
, ad_sourcetext CLOB 
, ad_finaltext CLOB 
, ad_fltextn NCLOB 
, ad_textdocs_ntab textdoc_tab 
, ad_photo BLOB 
, ad_graphic BFILE 
, ad_header adheader_typ 
) NESTED TABLE ad_textdocs_ntab STORE AS 
textdocs_nestedtab_demo 
LOB (ad_composite, ad_photo, ad_finaltext) 
STORE AS(STORAGE (INITIAL 20M)) 
PARTITION BY RANGE (product_id) 
(PARTITION p1 VALUES LESS THAN (3000) TABLESPACE 
tbs_01 
LOB (ad_composite, ad_photo) 


STORE AS (TABLESPACE tbs_02 STORAGE (INITIAL 
10M)) 

NESTED TABLE ad_textdocs_ntab STORE AS nt_p1 
(TABLESPACE example), 

PARTITION P2 VALUES LESS THAN (MAXVALUE) 

LOB (ad_composite, ad_finaltext) 

STORE AS SECUREFILE (TABLESPACE auto_seg_ts) 

NESTED TABLE ad_textdocs_ntab STORE AS nt_p2 


) 
TABLESPACE tbs_03; 


Partition p1 will be in tablespace tbs_01. The LOB data partitions 

for ad_composite and ad_photo will be in tablespace tbs_02. The LOB data 
partition for the remaining LOB columns will be in tablespace tbs_01. The 
storage attribute INITIAL is specified for LOB 

columns ad_composite and ad_photo. Other attributes will be inherited 
from the default table-level specification. The default LOB storage 
attributes not specified at the table level will be inherited from the 
tablespace tbs_02 for columns ad_composite and ad_photo and from 
tablespace tbs_01 for the remaining LOB columns. LOB index partitions 
will be in the same tablespaces as the corresponding LOB data partitions. 
Other storage attributes will be based on values of the corresponding 
attributes of the LOB data partitions and default attributes of the tablespace 
where the index partitions reside. The nested table partition for 
ad_textdocs_ntab will be stored as nt_p1 in tablespace example. 


Partition p2 will be in the default tablespace tbs_03. The LOB data 

for ad_composite and ad_finaltext will be in tablespace auto_seg_ts as 
SecureFiles LOBs. The LOB data for the remaining LOB columns will be 
in tablespace tbs_03. The LOB index for 

columns ad_composite and ad_finaltext will be in tablespace auto_seg_ts. 
The LOB index for the remaining LOB columns will be in 

tablespace tbs_03. The nested table partition for ad_textdocs_ntab will be 
stored as nt_p2 in the default tablespace tbs_03. 


Hash Partitioning Example 


The sample table oe.product_information is not partitioned. However, you 
might want to partition such a large table by hash for performance reasons, 
as shown in this example. The tablespace names are hypothetical in this 
example. 


CREATE TABLE hash_products 
( product_id NUMBER(6) PRIMARY KEY 
, product_name VARCHAR2(50) 
, product_description VARCHAR2(2000) 
, category_id NUMBER(2) 
, weight_class NUMBER(1) 
, walranty_period INTERVAL YEAR TO MONTH 
, supplier_id NUMBER(6) 
, product_status VARCHAR2(20) 
, list_price NUMBER(8,2) 
, min_price NUMBER(8,2) 
, catalog _url VARCHAR2(50) 
, CONSTRAINT product_status_lov_demo 
CHECK (product_status in (‘orderable' 
,'planned' 
„under development’ 
, obsolete’) 
)) 
PARTITION BY HASH (product_id) 
PARTITIONS 4 
STORE IN (tbs_01, tbs_02, tbs_03, tbs_04); 


Reference Partitioning Example 


The next statement uses the hash_products partitioned table created in the 
preceding example. It creates a variation of the oe.order_items table that is 
partitioned by reference to the hash partitioning on the product id 

of hash_products. The resulting child table will be created with five 
partitions. For each row of the child table part_order_items, the database 
evaluates the foreign key value (product_id) to determine the partition 
number of the parent table hash_products to which the referenced key 
belongs. The part_order_items row is placed in its corresponding partition. 


CREATE TABLE part_order_items ( 
order_id NUMBER(12) PRIMARY KEY, 
line_item_id NUMBER(3), 
product_id NUMBER(6) NOT NULL, 
unit_price NUMBER(8,2), 
quantity NUMBER(8), 
CONSTRAINT product_id_fk 
FOREIGN KEY (product_id) REFERENCES 
hash_products(product_id)) 
PARTITION BY REFERENCE (product_id_fk); 


Composite-Partitioned Table Examples 


If you plan to access recent data according to distribution channel as well as 
time, then composite partitioning might be more appropriate. The following 
example creates a copy of that range_sales table but specifies range-hash 
composite partitioning. The partitions with the most recent data are 
subpartitioned with both system-generated and user-defined subpartition 
names. Constraints and storage attributes have been omitted from the 
example. 


CREATE TABLE composite_sales 
( prod_id NUMBER(6) 
, cust_id NUMBER 
, time_id DATE 
,channel_id CHAR(1) 
, promo_id NUMBER(6) 
, quantity_sold NUMBER(3) 
, amount_sold NUMBER(10,2) 
) 
PARTITION BY RANGE (time_id) 
SUBPARTITION BY HASH (channel_id) 
(PARTITION SALES_Q1_1998 VALUES LESS THAN 
(TO_DATE('01-APR-1998',, DD-MON-YYYY’)), 
PARTITION SALES_Q2_1998 VALUES LESS THAN 
(TO_DATE('01-JUL-1998',,DD-MON-YYYY')), 


PARTITION SALES_Q3_1998 VALUES LESS THAN 
(TO_DATE('01-OCT-1998',tDD-MON-YYYY’)), 
PARTITION SALES_Q4_1998 VALUES LESS THAN 
(TO_DATE('01-JAN-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q1_1999 VALUES LESS THAN 
(TO_DATE('01-APR-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q2_1999 VALUES LESS THAN 
(TO_DATE('01-JUL-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q3_1999 VALUES LESS THAN 
(TO_DATE('01-OCT-1999',,DD-MON-YYYY’)), 
PARTITION SALES_Q4_1999 VALUES LESS THAN 
(TO_DATE('01-JAN-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q1_2000 VALUES LESS THAN 
(TO_DATE('01-APR-2000',,DD-MON-YYYY’)), 
PARTITION SALES_Q2_2000 VALUES LESS THAN 
(TO_DATE('01-JUL-2000',,DD-MON-YYYY’)) 
SUBPARTITIONS 8, 
PARTITION SALES_Q3_ 2000 VALUES LESS THAN 
(TO_DATE('01-OCT-2000',,DD-MON-YYYY’)) 
(SUBPARTITION ch_c, 
SUBPARTITION ch _i, 
SUBPARTITION ch _p, 
SUBPARTITION ch _s, 
SUBPARTITION ch _1), 
PARTITION SALES_Q4_2000 VALUES LESS THAN 
(MAXVALUE) 
SUBPARTITIONS 4) 


The following examples creates a partitioned table of customers based on 
the sample table oe.customers. In this example, the table is partitioned on 
the credit_limit column and list subpartitioned on the nls_territory column. 
The subpartition template determines the subpartitioning of any 
subsequently added partitions, unless you override the template by defining 
individual subpartitions. This composite partitioning makes it possible to 
query the table based on a credit limit range within a specified region: 


CREATE TABLE customers_part ( 
customer_id NUMBER(6), 
cust_first_name VARCHAR2(20), 
cust_last_name VARCHAR2(20), 
nls_territory VARCHAR2(30), 
credit_limit © NUMBER(9,2)) 
PARTITION BY RANGE (credit_limit) 
SUBPARTITION BY LIST (nls_territory) 
SUBPARTITION TEMPLATE 
(SUBPARTITION east VALUES 
(‘CHINA’', JAPAN’, 'INDIA', 'THAILAND’), 
SUBPARTITION west VALUES 
(‘AMERICA’, 'GERMANY'’, 'ITALY', 'SWITZERLAND’), 
SUBPARTITION other VALUES (DEFAULT)) 
(PARTITION p1 VALUES LESS THAN (1000), 
PARTITION p2 VALUES LESS THAN (2500), 
PARTITION p3 VALUES LESS THAN (MAXVALUB)); 


Object Column and Table Examples 
Creating Object Tables: Examples 
Consider object type department_typ: 


CREATE TYPE department_typ AS OBJECT 
(d_name VARCHAR2(100), 
d_address VARCHAR2(200) ); 
/ 


Object table departments_obj_t holds department objects of 
type department_typ: 


CREATE TABLE departments_obj_t OF department_typ; 


The following statement creates object table salesreps with a user-defined 
object type, salesrep_typ: 


CREATE OR REPLACE TYPE salesrep_typ AS OBJECT 
( repId NUMBER, 
repName VARCHAR2(64)); 


CREATE TABLE salesreps OF salesrep_typ; 


Creating a Table with a User-Defined Object Identifier: Example 


This example creates an object type and a corresponding object table whose 
object identifier is primary key based: 


CREATE TYPE employees_typ AS OBJECT 
(e_no NUMBER, e_address CHAR(30)); 
/ 


CREATE TABLE employees_obj_t OF employees_typ (e_no 
PRIMARY KEY) 
OBJECT IDENTIFIER IS PRIMARY KEY; 


You can subsequently reference the employees_obj_t object table using 
either inline_ref_constraint or out_of_line_ref_constraint syntax: 


CREATE TABLE departments_t 
(d_no NUMBER, 
mgr_ref REF employees_typ SCOPE IS employees_obj_t); 


CREATE TABLE departments_t ( 
d_no NUMBER, 
mgr_ref REF employees_typ 
CONSTRAINT mgr_in_emp REFERENCES employees_obj_t); 


Specifying Constraints on Type Columns: Example 


The following example shows how to define constraints on attributes of an 
object type column: 


CREATE TYPE address_t AS OBJECT 
(hno NUMBER, 
street VARCHAR2(40), 
city VARCHAR2(20), 
zip VARCHAR2(5), 
phone VARCHAR2(10) ); 
/ 


CREATE TYPE person AS OBJECT 
(name VARCHAR2(40), 
dateofbirth DATE, 
homeaddress address_t, 
manager REF person ); 
/ 


CREATE TABLE persons OF person 
( homeaddress NOT NULL, 
UNIQUE (homeaddress.phone), 
CHECK (homeaddress.zip IS NOT NULL), 
CHECK (homeaddress.city <> 'San Francisco’) ); 


ALTER TABLE 


Use the ALTER TABLE statement to alter the definition of a nonpartitioned 
table, a partitioned table, a table partition, or a table subpartition. For object 
tables or relational tables with object columns, use ALTER TABLE to 
convert the table to the latest definition of its referenced type after the type 
has been altered. 


The table must be in your own schema, or you must have ALTER object 
privilege on the table, or you must have ALTER ANY TABLE system 
privilege. 

Additional Prerequisites for Partitioning Operations 


If you are not the owner of the table, then you need 
the DROP ANY TABLE privilege in order to use the drop_table_partition 
or truncate_table_partition clause. 


You must also have space quota in the tablespace in which space is to be 
acquired in order to use the add_table_partition , modify_table_partition , 
move_table_partition , and split_table_partition clauses. 


When a partitioning operation cascades to reference-partitioned child tables, 
privileges are not required on the reference-partitioned child tables. 


When using the exchange_partition_subpart clause, if the table data being 
exchanged contains an identity column and you are not the owner of both 
tables involved in the exchange, then you must have 

the ALTER ANY SEQUENCE system privilege. 


You cannot partition a non-partitioned table that has an object type. 
Additional Prerequisites for Constraints and Triggers 


To enable a unique or primary key constraint, you must have the privileges 
necessary to create an index on the table. You need these privileges because 
Oracle Database creates an index on the columns of the unique or primary 
key in the schema containing the table. 


To enable or disable triggers, the triggers must be in your schema or you 
must have the ALTER ANY TRIGGER system privilege. 


Additional Prerequisites When Using Object Types 


To use an object type in a column definition when modifying a table, either 
that object must belong to the same schema as the table being altered, or 
you must have either the EXECUTE ANY TYPE system privilege or 

the EXECUTE object privilege for the object type. 


Additional Prerequisites for Flashback Data Archive Operations 


To use the flashback_archive_clause to enable historical tracking for the 
table, you must have the FLASHBACK ARCHIVE object privilege on the 
flashback data archive that will contain the historical data. To use the 
flashback_archive_clause to disable historical tracking for the table, you 
must have the FLASHBACK ARCHIVE ADMINSTER system privilege or 
you must be logged in as SYSDBA. 


Additional Prerequisite for Referring to Editioned Objects 


To specify an edition in the evaluation_edition_clause or the 
unusable_editions_clause , you must have the USE privilege on the edition. 


Examples 
Adding Constraints to Tables: Example 


The following statements create a new table to manipulate data and display 
the information in the newly created table: 


CREATE TABLE JOBS_Temp AS SELECT * FROM HR.JOBS; 
SELECT * FROM JOBS_Temp WHERE MIN_SALARY < 3000; 


JOB_ID JOB_TITLE MIN_SALARY MAX SALARY 


PU_CLERK Purchasing Clerk 2500 5500 
ST_CLERK Stock Clerk 2008 5000 
SH_CLERK Shipping Clerk 2500 5500 


The following statement updates the column values to a higher value: 


UPDATE JOBS_Temp SET MIN_SALARY = 2300 WHERE 
MIN_SALARY < 2010; 


The following statement adds a constraint: 


ALTER TABLE JOBS_Temp ADD CONSTRAINT chk_sal_min 
CHECK (MIN_SALARY >=2010); 


The following statement displays the table information: 


SELECT * FROM JOBS_Temp WHERE MIN_SALARY < 3000; 


JOB_ID JOB_TITLE MIN_SALARY MAX _ SALARY 
PU_CLERK Purchasing Clerk 2500 5500 

ST_CLERK Stock Clerk 2300 5000 

SH_CLERK Shipping Clerk 2500 5500 


The following statement displays the constraint: 


SELECT CONSTRAINT _NAME FROM USER_CONSTRAINTS 
WHERE TABLE NAME="JOBS_TEMP'; 


CONSTRAINT_NAME 


SYS_C008830 
CHK_SAL_MIN 


Collection Retrieval: Example 


The following statement modifies nested table column ad_textdocs_ntab in 
the sample table sh.print_media so that when queried it returns actual 
values instead of locators: 


ALTER TABLE print_media MODIFY NESTED TABLE 
ad_textdocs_ntab 
RETURN AS VALUE; 


Specifying Parallel Processing: Example 


The following statement specifies parallel processing for queries to the 
sample table oe.customers: 


ALTER TABLE customers 
PARALLEL; 


Changing the State of a Constraint: Examples 


The following statement places in ENABLE VALIDATE state an integrity 
constraint named emp_manager_fk in the employees table: 


ALTER TABLE employees 
ENABLE VALIDATE CONSTRAINT emp_manager_fk 


EXCEPTIONS INTO exceptions; 


Each row of the employees table must satisfy the constraint for Oracle 
Database to enable the constraint. If any row violates the constraint, then 
the constraint remains disabled. The database lists any exceptions in the 
table exceptions. You can also identify the exceptions in 

the employees table with the following statement: 


SELECT e.* 
FROM employees e, exceptions ex 
WHERE e.rowid = ex.row_id 
AND ex.table_name = 'EMPLOYEES' 
AND ex.constraint = 'EMP MANAGER FK'; 


The following statement tries to place in ENABLE NOVALIDATE state 
two constraints on the employees table: 


ALTER TABLE employees 
ENABLE NOVALIDATE PRIMARY KEY 
ENABLE NOVALIDATE CONSTRAINT emp_last_name_nn; 


This statement has two ENABLE clauses: 


The first places a primary key constraint on the table 
in ENABLE NOVALIDATE state. 


- The second places the constraint 
named emp_last_name_nn in ENABLE NOVALIDATE state. 


In this case, Oracle Database enables the constraints only if both are 
satisfied by each row in the table. If any row violates either constraint, then 
the database returns an error and both constraints remain disabled. 


Consider the foreign key constraint on the location_id column of 

the departments table, which references the primary key of 

the locations table. The following statement disables the primary key of 
the locations table: 


ALTER TABLE locations 
MODIFY PRIMARY KEY DISABLE CASCADE; 


The unique key in the locations table is referenced by the foreign key in 
the departments table, so you must specify CASCADE to disable the 
primary key. This clause disables the foreign key as well. 


Creating an Exceptions Table for Index-Organized Tables: Example 


The following example creates the except_table table to hold rows from the 
index-organized table hr.countries that violate the primary key constraint: 


EXECUTE DBMS_IOT.BUILD_EXCEPTIONS_TABLE (hr, 
‘countries’, 'except_table'); 
ALTER TABLE countries 

ENABLE PRIMARY KEY 

EXCEPTIONS INTO except_table; 


To specify an exception table, you must have the privileges necessary to 
insert rows into the table. To examine the identified exceptions, you must 
have the privileges necessary to query the exceptions table. 


Disabling a CHECK Constraint: Example 


The following statement defines and disables a CHECK constraint on 
the employees table: 


ALTER TABLE employees ADD CONSTRAINT check_comp 
CHECK (salary + (commission_pct*salary) <= 5000) 
DISABLE; 


The constraint check_comp ensures that no employee's total compensation 
exceeds $5000. The constraint is disabled, so you can increase an 
employee's compensation above this limit. 


Enabling Triggers: Example 


The following statement enables all triggers associated with 
the employees table: 


ALTER TABLE employees 
ENABLE ALL TRIGGERS; 


Deallocating Unused Space: Example 


The following statement frees all unused space for reuse in 
table employees, where the high water mark is above MINEXTENTS: 


ALTER TABLE employees 
DEALLOCATE UNUSED; 


Modifying the Collation of a Column for Fine-Grained Case- 
Insensitivity: Example 


This example shows how to modify a column to be case-insensitive. First, 
create and populate table students as follows: 


CREATE TABLE students (last_name VARCHAR2(20), id 
NUMBER); 


INSERT INTO students VALUES(‘Dodd'’, 364); 
INSERT INTO students VALUES(‘de Niro’, 132); 
INSERT INTO students VALUES('Vogel', 837); 
INSERT INTO students VALUES(‘'van der Kamp', 549); 
INSERT INTO students VALUES('van Der Meer', 624); 


The following statement returns column last_name in alphabetical order. 
Notice that the results are case-sensitive; lowercase letters are ordered after 
uppercase letters. 


SELECT last_name, id 
FROM students 
ORDER BY last_name; 


LAST_NAME ID 


Dodd 364 
Vogel 837 
de Niro 132 
van Der Meer 624 
van der Kamp 549 


The following statement changes the data-bound collation of 
column last_name to case-insensitive collation BINARY_CI: 


ALTER TABLE students 
MODIFY (last_name COLLATE BINARY_CI); 


The following statement again returns column last_name in alphabetical 
order. Notice that the results are now case-insensitive: 


SELECT last_name, id 
FROM students 
ORDER BY last_name; 


LAST_NAME ID 
de Niro 132 
Dodd 364 

van der Kamp 549 
van Der Meer 624 
Vogel 837 


Renaming a Column: Example 


The following example renames the credit_limit column of the sample 
table oe.customers to credit_amount: 


ALTER TABLE customers 


RENAME COLUMN credit_limit TO credit_amount; 


Dropping a Column: Example 


This statement illustrates the drop_column_clause 
with CASCADE CONSTRAINTS. Assume table t1 is created as follows: 


CREATE TABLE tl ( 
pk NUMBER PRIMARY KEY, 
fk NUMBER, 
cl NUMBER, 
c2 NUMBER, 
CONSTRAINT ri FOREIGN KEY (fk) REFERENCES t1, 
CONSTRAINT ck1 CHECK (pk > 0 and c1 > 0), 
CONSTRAINT ck2 CHECK (c2 > 0) 


); 
An error will be returned for the following statements: 


/* The next two statements return errors: 

ALTER TABLE t1 DROP (pk); -- pk is a parent key 

ALTER TABLE t1 DROP (c1); -- c1 is referenced by multicolumn 
-- constraint ck1 


Submitting the following statement drops column pk, the primary key 
constraint, the foreign key constraint, ri, and the check constraint, ck1: 


ALTER TABLE t1 DROP (pk) CASCADE CONSTRAINTS; 


If all columns referenced by the constraints defined on the dropped columns 
are also dropped, then CASCADE CONSTRAINTS is not required. For 
example, assuming that no other referential constraints from other tables 
refer to column pk, then it is valid to submit the following statement 
without the CASCADE CONSTRAINTS clause: 


ALTER TABLE t1 DROP (pk, fk, c1); 


Dropping Unused Columns: Example 


The following statements create a new table to manipulate data and display 
the information in the newly created table: 


CREATE TABLE JOBS_Temp AS SELECT * FROM HR.JOBS; 
SELECT * FROM JOBS_Temp WHERE MAX_SALARY > 20000; 


JOB_ID JOB_TITLE MIN_SALARY MAX SALARY 


AD _ PRES President 20080 40000 
AD_VP Administration Vice President 15000 30000 
SA_MAN Sales Manager 10000 20080 


The following statement adds two new columns: 


ALTER TABLE JOBS_Temp ADD (DUMMY1 NUMBER(2), 
DUMMY2 NUMBER(2)); 


The following statements inserts values into the newly added columns: 


INSERT INTO JOBS_Temp(JOB_ID, JOB_TITLE, DUMMY1, 
DUMMY2) VALUES (‘D',, DUMMY ',10,20); 
INSERT INTO JOBS_Temp(JOB_ID, JOB_TITLE, DUMMY1, 
DUMMY2) VALUES (‘D',, DUMMY',10,20) 


The following statement sets the newly added columns to unused: 


ALTER TABLE JOBS_TEMP SET UNUSED (DUMMY1, 
DUMMY?2); 


The following statement displays the count of unused columns: 


SELECT * FROM USER_UNUSED_COL_TABS WHERE 
TABLE NAME="JOBS_TEMP'; 


TABLE NAM COUNT 


JOBS_TEMP 2 
The following statement drops the unused columns: 

ALTER TABLE JOBS_TEMP DROP UNUSED COLUMNS; 
The following statement displays the table information: 


SELECT * FROM JOBS_TEMP; 


JOB_ID JOB_TITLE MIN_SALARY MAX _ SALARY 
AD_PRES President 20080 40000 

AD VP Administration Vice President 15000 30000 
AD_ASST Administration Assistant 3000 6000 

FI MGR Finance Manager 8200 16000 
FI_ACCOUNT Accountant 4200 9000 

AC_MGR_ Accounting Manager 8200 16000 
AC_ACCOUNT Public Accountant 4200 9000 
SA_MAN Sales Manager 10000 20080 

SA_REP Sales Representative 6000 12008 
PU_MAN Purchasing Manager 8000 15000 
PU_CLERK Purchasing Clerk 2500 5500 

ST_MAN Stock Manager 5500 8500 

ST_CLERK Stock Clerk 2008 5000 

SH_CLERK Shipping Clerk 2500 5500 

IT_PROG Programmer 4000 10000 

MK_MAN Marketing Manager 9000 15000 


MK_REP Marketing Representative 4000 9000 
HR_REP Human Resources Representative 4000 9000 
PR_REP Public Relations Representative 4500 10500 
D DUMMY 

D DUMMY 


Modifying Index-Organized Tables: Examples 


This statement modifies the INITRANS parameter for the index segment of 
index-organized table countries_demo, which is based on hr.countries: 


ALTER TABLE countries_demo INITRANS 4; 


The following statement adds an overflow data segment to index-organized 
table countries: 


ALTER TABLE countries_ demo ADD OVERFLOW; 


This statement modifies the INITRANS parameter for the overflow data 
segment of index-organized table countries: 


ALTER TABLE countries_demo OVERFLOW INITRANS 4; 


Splitting Table Partitions: Examples 


The following statement splits the old partition sales_q4_2000 in the 
sample table sh.sales, creating two new partitions, naming 
one sales_q4_2000b and reusing the name of the old partition for the other: 


ALTER TABLE sales SPLIT PARTITION SALES _Q4 2000 
AT (TO_DATE('15-NOV-2000',,DD-MON-YYYY’)) 
INTO (PARTITION SALES _Q4 2000, PARTITION 

SALES_Q4_2000b); 


The following statement splits the old partition sales_q1_2002 into three 
new partitions sales_jan_2002, sales_feb_2002, and sales_mar_2002: 


ALTER TABLE sales SPLIT PARTITION SALES_Q1_2002 INTO ( 
PARTITION SALES_JAN_2002 VALUES LESS THAN 
(TO_DATE(01-FEB-2002',,DD-MON-YYYY’)), 

PARTITION SALES_FEB_2002 VALUES LESS THAN 
(TO_DATE('01-MAR-2002',,DD-MON-YYYY’)), 

PARTITION SALES_MAR_2002); 


The following statements create a partitioned version of the pm.print_media 
table. The LONG column in the print_media table has been converted to 
LOB. The object types underlying 

the ad_textdocs_ntab and ad_header columns are created in the script that 
creates the pm sample schema: 


CREATE TABLE print_media_part ( 
product_id NUMBER(6), 
ad_id NUMBER(6), 
ad_composite BLOB, 
ad_sourcetext CLOB, 
ad_finaltext CLOB, 
ad_fltextn NCLOB, 
ad_textdocs_ntab TEXTDOC_TAB, 
ad_photo BLOB, 
ad_ graphic BFILE, 
ad_header ADHEADER_TYP) 
NESTED TABLE ad_textdocs_ntab STORE AS textdoc_nt 
PARTITION BY RANGE (product_id) 
(PARTITION p1 VALUES LESS THAN (100), 
PARTITION p2 VALUES LESS THAN (200)); 


The following statement splits partition p2 of that table into 
partitions p2a and p2b: 


ALTER TABLE print_media_part 
SPLIT PARTITION p2 AT (150) INTO 
(PARTITION p2a TABLESPACE omf_ts1 
LOB (ad_photo, ad_composite) STORE AS (TABLESPACE 
omf_ts2), 
PARTITION p2b 
LOB (ad_photo, ad_composite) STORE AS (TABLESPACE 
omf_ts2)) 
NESTED TABLE ad_textdocs_ntab INTO (PARTITION nt_p2a, 
PARTITION nt_p2b); 


In both partitions p2a and p2b, Oracle Database creates the LOB segments 
for columns ad_photo and ad_composite in tablespace omf_ts2. The LOB 
segments for the remaining columns in partition p2a are stored in tablespace 
omf_ts1. The LOB segments for the remaining columns in partition p2b 
remain in the tablespaces in which they resided prior to 

this ALTER statement. However, the database creates new segments for all 
the LOB data and LOB index segments, even if they are not moved to a 
new tablespace. 


The database also creates new segments for nested table 
column ad_textdocs_ntab. The storage tables is those new segments 
are nt_p2a and nt_p2b. 


Merging Two Table Partitions: Example 


The following statement merges back into one partition: 


ALTER TABLE sales 
MERGE PARTITIONS sales_q4_2000, sales_q4_2000b 
INTO PARTITION sales_q4_ 2000; 


The next statement reverses the example: 


ALTER TABLE print_media_part 
MERGE PARTITIONS p2a, p2b INTO PARTITION p2ab 
TABLESPACE example 


NESTED TABLE ad_textdocs_ntab STORE AS nt_p2ab; 


Merging Four Adjacent Range Partitions: Example 


The following statement merges four adjacent range 
partitions, sales_qi_2000, sales_q2_ 2000, sales_q3_ 2000, 
and sales_q4_2000 into one partition sales_all_ 2000: 


ALTER TABLE sales 
MERGE PARTITIONS sales_q1_2000 TO sales_q4_2000 
INTO PARTITION sales_all_ 2000; 


Adding a Table Partition with a LOB and Nested Table Storage: 
Examples 


The following statement adds a partition p3 to the print_media_part table 
(see preceding example) and specifies storage characteristics for 
the BLOB, CLOB, and nested table columns of that table: 


ALTER TABLE print_media_part ADD PARTITION p3 VALUES 
LESS THAN (400) 

LOB(ad_photo, ad_composite) STORE AS (TABLESPACE 
omf_ts1) 

LOB(ad_sourcetext, ad_finaltext) STORE AS (TABLESPACE 
omf_ts2) 

NESTED TABLE ad_textdocs_ntab STORE AS nt_p3; 


The LOB data and LOB index segments for 

columns ad_photo and ad_composite in partition p3 will reside in 
tablespace omf_ts1. The remaining attributes for these LOB columns will 
be inherited first from the table-level defaults, and then from the tablespace 
defaults. 


The LOB data segments for columns ad_source_text and ad_finaltext will 
reside in the omf_ts2 tablespace, and will inherit all other attributes first 
from the table-level defaults, and then from the tablespace defaults. 


The partition for the storage table for nested table storage 

column ad_textdocs_ntab corresponding to partition p3 of the base table is 
named nt_p3 and inherits all other attributes first from the table-level 
defaults, and then from the tablespace defaults. 


Adding Multiple Partitions to a Table: Example 


The following statement adds three partitions to the table print_media_part : 


ALTER TABLE print_media_part ADD 
PARTITION p3 values less than (300), 
PARTITION p4 values less than (400), 
PARTITION p5 values less than (500); 


Working with Default List Partitions: Example 


The following statements use the list partitioned table. The first statement 
splits the existing default partition into a new south partition and a default 
partition: 


ALTER TABLE list_customers SPLIT PARTITION rest 
VALUES (‘MEXICO’, 'COLOMBIA') 
INTO (PARTITION south, PARTITION rest); 


The next statement merges the resulting default partition with 
the asia partition: 


ALTER TABLE list_customers 
MERGE PARTITIONS asia, rest INTO PARTITION rest; 


The next statement re-creates the asia partition by splitting the default 
partition: 


ALTER TABLE list_customers SPLIT PARTITION rest 
VALUES (‘CHINA’, "THAILAND') 
INTO (PARTITION asia, PARTITION rest); 


Dropping a Table Partition: Example 


The following statement drops partition p3 : 
ALTER TABLE print_media_part DROP PARTITION p3; 


Exchanging Table Partitions: Example 


This example creates the table exchange_table with the same structure as 
the partitions of the list_customers table. It then replaces partition rest of 
table list_customers with table exchange_table without exchanging local 
index partitions with corresponding indexes on exchange_table and without 
verifying that data in exchange_table falls within the bounds of 

partition rest: 


CREATE TABLE exchange_table ( 
customer_id NUMBER(6), 
cust_first_name VARCHAR2(20), 
cust_last_name VARCHAR2(20), 
cust_address CUST_ADDRESS_TYP, 
nls_territory VARCHAR2(30), 
cust_email VARCHAR2(40)); 


ALTER TABLE list_customers 
EXCHANGE PARTITION rest WITH TABLE exchange_table 
WITHOUT VALIDATION; 


Modifying Table Partitions: Examples 


The following statement marks all the local index partitions corresponding 
to the asia partition of the list_customers table UNUSABLE: 


ALTER TABLE list_customers MODIFY PARTITION asia 
UNUSABLE LOCAL INDEXES; 


The following statement rebuilds all the local index partitions that were 
marked UNUSABLE: 


ALTER TABLE list_customers MODIFY PARTITION asia 
REBUILD UNUSABLE LOCAL INDEXES; 


Moving Table Partitions: Example 


The following statement moves partition p2b to tablespace omf_ts1: 


ALTER TABLE print_media_part 
MOVE PARTITION p2b TABLESPACE omf_ts1; 


Renaming Table Partitions: Examples 


The following statement renames a partition of the sh.sales table: 


ALTER TABLE sales RENAME PARTITION sales_g4_2003 TO 
sales_currentq; 


Truncating Table Partitions: Example 


The following statement uses the print_media_demo table. It deletes all the 
data in the p1 partition and deallocates the freed space: 


ALTER TABLE print_media_demo 
TRUNCATE PARTITION p1 DROP STORAGE; 


Updating Global Indexes: Example 


The following statement splits partition sales_q1_2000 of the sample 
table sh.sales and updates any global indexes defined on it: 


ALTER TABLE sales SPLIT PARTITION sales_q1_2000 
AT (TO_DATE(‘16-FEB-2000',,DD-MON-YYYY')) 
INTO (PARTITION q1a_2000, PARTITION q1b_2000) 
UPDATE GLOBAL INDEXES; 


Updating Partitioned Indexes: Example 


The following statement splits partition costs_Q4_ 2003 of the sample 
table sh.costs and updates the local index defined on it. It uses the 
tablespaces. 


CREATE INDEX cost_ix ON costs(channel_id) LOCAL; 


ALTER TABLE costs 
SPLIT PARTITION costs_q4_2003 at 
(TO_DATE(‘01-Nov-2003','dd-mon-yyyy’)) 
INTO (PARTITION c_p1, PARTITION c_p2) 
UPDATE INDEXES (cost_ix (PARTITION c_p1 tablespace tbs_02, 
PARTITION c_p2 tablespace tbs_03)); 


Specifying Object Identifiers: Example 


The following statements create an object type, a corresponding object table 
with a primary-key-based object identifier, and a table having a user- 
defined REF column: 


CREATE TYPE emp_t AS OBJECT (empno NUMBER, address 
CHAR(30)); 


CREATE TABLE emp OF emp_t ( 
empno PRIMARY KEY) 
OBJECT IDENTIFIER IS PRIMARY KEY; 


CREATE TABLE dept (dno NUMBER, mgr_ref REF emp_t SCOPE 
is emp); 


The next statements add a constraint and a user-defined REF column, both 
of which reference table emp 


ALTER TABLE dept ADD CONSTRAINT mgr_cons FOREIGN 
KEY (megr_ref) 
REFERENCES emp; 


ALTER TABLE dept ADD sr_mgr REF emp_t REFERENCES emp; 


Adding a Table Column: Example 


The following statement adds to the countries table a column 
named duty_pct of data type NUMBER and a column 

named visa_needed of data type VARCHAR2 with a size of 3 and 
a CHECK integrity constraint: 


ALTER TABLE countries 
ADD (duty_pct NUMBER(2,2) CHECK (duty_pct < 10.5), 
visa_needed VARCHAR2(3)); 


Adding a Virtual Table Column: Example 


The following statement adds to a of the hr.employees table a column 
named income, which is a combination of salary plus commission. Both 
salary and commission are NUMBER columns, so the database creates the 
virtual column as a NUMBER column even though the data type is not 
specified in the statement: 


CREATE TABLE emp2 AS SELECT * FROM employees; 


ALTER TABLE emp2 ADD (income AS (salary + 
(salary*commission_pct))); 


Modifying Table Columns: Examples 


The following statement increases the size of the duty_pct column: 


ALTER TABLE countries 
MODIFY (duty_pct NUMBER(3,2)); 


Because the MODIFY clause contains only one column definition, the 
parentheses around the definition are optional. 


The following statement changes the values of 
the PCTFREE and PCTUSED parameters for the employees table to 30 and 
60, respectively: 


ALTER TABLE employees 
PCTFREE 30 
PCTUSED 60; 


Modifying Storage Attributes for a Table 


The following statement creates a table named JOBS_TEMP by using the 
existing JOBS table: 


CREATE TABLE JOBS_TEMP AS SELECT * FROM HR.JOBS; 


The following statement queries the USER_TABLES table for storage 
parameters: 


SELECT initial_ extent, 
next_extent, 
min_extents, 
max_extents, 
pct_increase, 
blocks, 
sample_size 
FROM user_tables 
WHERE table_name = 'JOBS_ TEMP’; 


INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS 
MAX_EXTENTS PCT_INCREASE BLOCKS SAMPLE SIZE 


65536 = 1048576 1 2147483645 1 19 


The following statement alters the JOBS_TEMP table with new storage 
parameters: 


ALTER TABLE JOBS_TEMP MOVE 
STORAGE (INITIAL 20K 
NEXT 40K 
MINEXTENTS 2 
MAXEXTENTS 20 
PCTINCREASE 0 ) 
TABLESPACE USERS; 


The following statement queries the USER_TABLES table for the new 
storage parameters: 


SELECT initial_ extent, 
next_extent, 
min_extents, 
max_extents, 
pct_increase, 
blocks, 
sample_size 
FROM user_tables 
WHERE table_name = 'JOBS_TEMP'; 


INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS 
MAX_EXTENTS PCT_INCREASE BLOCKS SAMPLE SIZE 


65536 40960 1 2147483645 1 19 


Adding, Altering, Renaming and Dropping Table Columns: Example 


The following statements create a new table to manipulate data and display 
the information in the newly created table: 


CREATE TABLE JOBS_Temp AS SELECT * FROM HR.JOBS; 


SELECT * FROM JOBS_Temp WHERE MAX_SALARY > 30000; 


JOB_ID JOB_TITLE MIN_SALARY MAX SALARY 


AD_PRES President 20080 40000 
The following statement modifies an existing column definition: 


ALTER TABLE JOBS_Temp MODIFY(JOB_TITLE 
VARCHAR2(100)); 


The following statement adds two new columns to the table: 


ALTER TABLE JOBS_Temp ADD (BONUS NUMBER (7,2), 
COMM NUMBER (5,2), DUMMY NUMBER(2)); 


The following statement displays the newly added columns: 


SELECT JOB_ID, BONUS, COMM, DUMMY FROM JOBS_Temp 
WHERE MAX_SALARY > 20000; 


JOB_ID BONUS COMM DUMMY 
AD_PRES 

AD_VP 

SA_MAN 


The following statements rename an existing column and display the 
modified column: 


ALTER TABLE JOBS_Temp RENAME COLUMN COMM TO 
COMMISSION; 


SELECT JOB_ID, COMMISSION FROM JOBS_Temp WHERE 
MAX_SALARY > 20000; 


JOB_ID COMMISSION 


AD_PRES 
AD_VP 
SA_MAN 


The following statement drops a single column from the table: 
ALTER TABLE JOBS_Temp DROP COLUMN DUMMY; 

The following statement drops multiple columns from the table: 
ALTER TABLE JOBS_Temp DROP (BONUS, COMMISSION); 


Data Encryption: Examples 


The following statement encrypts the salary column of 

the hr.employees table using the encryption algorithm AES256. As 
described in "Semantics" above, you must first enable Transparent Data 
Encryption: 


ALTER TABLE employees 
MODIFY (salary ENCRYPT USING 'AES256' 'NOMAC’); 


The following statement adds a new encrypted column online_acct_pw to 
the oe.customers table, using the default encryption algorithm AES192. 
Specifying NO SALT will allow a B-tree index to be created on the column, 
if desired. 


ALTER TABLE customers 
ADD (online_acct_pw VARCHAR2(8) ENCRYPT 'NOMAC' NO 
SALT); 


The following example decrypts the customer.online_acct_pw column: 


ALTER TABLE customers 
MODIFY (online_acct_pw DECRYPT); 


Allocating Extents: Example 


The following statement allocates an extent of 5 kilobytes for 
the employees table and makes it available to instance 4: 


ALTER TABLE employees 
ALLOCATE EXTENT (SIZE 5K INSTANCE 4); 


Because this statement omits the DATAFILE parameter, Oracle Database 
allocates the extent in one of the data files belonging to the tablespace 
containing the table. 


Specifying a Default Column Value: Examples 


This statement modifies the min_price column of 
the product_information table so that it has a default value of 10: 


ALTER TABLE product_information 
MODIFY (min_price DEFAULT 10); 


If you subsequently add a new row to the product_information table and do 
not specify a value for the min_price column, then the value of 
the min_price column is automatically 10: 


INSERT INTO product_information (product_id, product_name, 
list_price) 
VALUES (300, ‘left-handed mouse’, 40.50); 


SELECT product_id, product_name, list_price, min_price 
FROM product_information 
WHERE product_id = 300; 


PRODUCT_ID PRODUCT_NAME LIST_PRICE MIN_PRICE 


300 left-handed mouse 40.5 10 


To discontinue previously specified default values, so that they are no 
longer automatically inserted into newly added rows, replace the values 
with NULL, as shown in this statement: 


ALTER TABLE product_information 
MODIFY (min_price DEFAULT NULL); 


The MODIFY clause need only specify the column name and the modified 
part of the definition, rather than the entire column definition. This 
statement has no effect on any existing values in existing rows. 


The following example adds a column defined 
with DEFAULT ON NULL to a table. The DEFAULT column value 
includes the sequence pseudocolumn NEXTVAL. 


Create sequence s1 and table t1 as follows: 


CREATE SEQUENCE s1 START WITH 1; 


CREATE TABLE t1 (name VARCHAR2(10)); 
INSERT INTO t1 VALUES(Kevin); 

INSERT INTO t1 VALUES(‘Julia’); 

INSERT INTO t1 VALUES(Ryan’); 


Add column id, which defaults to s1.NEXTVAL. The default column value 
for id is assigned to each existing row in the table. The order in 
which s1.NEXTVAL is assigned to each row is nondeterministic. 


ALTER TABLE t1 ADD (id NUMBER DEFAULT ON NULL 
s1.NEXTVAL NOT NULL); 


SELECT id, name FROM t1 ORDER BY id; 


ID NAME 


1 Kevin 
2 Julia 
3 Ryan 


If you subsequently add a new row to the table and specify a NULL value 
for the id column, then 
the DEFAULT ON NULL expression s1.NEXTVAL is inserted. 


INSERT INTO t1(id, name) VALUES(NULL, 'Sean’); 
SELECT id, name FROM t1 ORDER BY id; 


ID NAME 


1 Kevin 
2 Julia 
3 Ryan 
4 Sean 


Adding a Constraint to an XMLType Table: Example 


The following example adds a primary key constraint to 
the xwarehouses table: 


ALTER TABLE xwarehouses 
ADD (PRIMARY KEY(XMLDATA."WarehouseID")); 


Renaming Constraints: Example 


The following statement renames the cust_fname_nn constraint on the 
sample table oe.customers to cust_firstname_nn: 


ALTER TABLE customers RENAME CONSTRAINT cust_fname_nn 
TO cust_firstname_nn; 


Dropping Constraints: Examples 


The following statement drops the primary key of the departments table: 


ALTER TABLE departments 
DROP PRIMARY KEY CASCADE; 


If you know that the name of the PRIMARY KEY constraint is pk_dept, 
then you could also drop it with the following statement: 


ALTER TABLE departments 
DROP CONSTRAINT pk_dept CASCADE; 


The CASCADE clause causes Oracle Database to drop any foreign keys 
that reference the primary key. 


The following statement drops the unique key on the email column of 
the employees table: 


ALTER TABLE employees 
DROP UNIQUE (email); 


The DROP clause in this statement omits the CASCADE clause. Because of 
this omission, Oracle Database does not drop the unique key if any foreign 
key references it. 


LOB Columns: Examples 


The following statement adds CLOB column resume to the employee table 
and specifies LOB storage characteristics for the new column: 


ALTER TABLE employees ADD (resume CLOB) 
LOB (resume) STORE AS resume_seg (TABLESPACE example); 


To modify the LOB column resume to use caching, enter the following 
statement: 


ALTER TABLE employees MODIFY LOB (resume) (CACHE); 


The following statement adds a SecureFiles CLOB column resume to 
the employee table and specifies LOB storage characteristics for the new 
column. SecureFiles LOBs must be stored in tablespaces with automatic 
segment-space management. Therefore, the LOB data in this example is 
stored in the auto_seg_ts tablespace: 


ALTER TABLE employees ADD (resume CLOB) 
LOB (resume) STORE AS SECUREFILE resume_seg 
(TABLESPACE auto_seg_ts); 


To modify the LOB column resume so that it does not use caching, enter the 
following statement: 


ALTER TABLE employees MODIFY LOB (resume) (NOCACHE); 


Nested Tables: Examples 


The following statement adds the nested table column skills to 
the employee table: 


ALTER TABLE employees ADD (skills skill_table_type) 
NESTED TABLE skills STORE AS nested_skill_table; 


You can also modify nested table storage characteristics. Use the name of 
the storage table specified in the nested_table_col_properties to make the 
modification. You cannot query or perform DML statements on the storage 
table. Use the storage table only to modify the nested table column storage 
characteristics. 


The following statement creates table vet_service with nested table 
column client and storage table client_tab. Nested table client_tab is 
modified to specify constraints: 


CREATE TYPE pet_t AS OBJECT 
(pet_id NUMBER, pet_name VARCHAR2(10), pet_dob DATE); 
/ 


CREATE TYPE pet AS TABLE OF pet_t; 
/ 


CREATE TABLE vet_service (vet_name VARCHAR2(30), 
client pet) 
NESTED TABLE client STORE AS client_tab; 


ALTER TABLE client_tab ADD UNIQUE (pet_id); 


The following statement alters the storage table for a nested table 
of REF values to specify that the REF is scoped: 


CREATE TYPE emp_t AS OBJECT (eno number, ename char(31)); 

CREATE TYPE emps_t AS TABLE OF REF emp_t; 

CREATE TABLE emptab OF emp_t; 

CREATE TABLE dept (dno NUMBER, employees emps_t) 
NESTED TABLE employees STORE AS deptemps; 

ALTER TABLE deptemps ADD (SCOPE FOR (COLUMN_VALUE) 

IS emptab); 


Similarly, to specify storing the REF with rowid: 


ALTER TABLE deptemps ADD (REF(column_value) WITH 
ROWID); 


In order to execute these ALTER TABLE statements successfully, the 
storage table deptemps must be empty. Also, because the nested table is 
defined as a table of scalar values (REF values), Oracle Database implicitly 
provides the column name COLUMN_VALUE for the storage table. 


REF Columns: Examples 


The following statement creates an object type dept_t and then creates 
table staff: 


CREATE TYPE dept_t AS OBJECT 
(deptno NUMBER, dname VARCHAR2(20)); 
/ 


CREATE TABLE staff 
(name VARCHAR2(100), 
salary NUMBER, 
dept REF dept_t); 


An object table offices is created as: 
CREATE TABLE offices OF dept_t; 


The dept column can store references to objects of dept_t stored in any 

table. If you would like to restrict the references to point only to objects 
stored in the departments table, then you could do so by adding a scope 
constraint on the dept column as follows: 


ALTER TABLE staff 
ADD (SCOPE FOR (dept) IS offices); 


The preceding ALTER TABLE statement will succeed only if the staff table 
is empty. 


If you want the REF values in the dept column of staff to also store the 
rowids, then issue the following statement: 


ALTER TABLE staff 
ADD (REF(dept) WITH ROWID); 


Unpacked Storage in ANYDATA Columns: Example 


This example creates a table with an ANYDATA column, stores opaque 
data types in the ANYDATA column using unpacked storage, and then 
queries the data types. This example assumes that you are connected to the 
database as user hr. 


Create table t1, which contains a NUMBER column n and 
an ANYDATA column x: 


CREATE TABLE t1 (n NUMBER, x ANYDATA); 


Create an object type clob_typ, which contains a CLOB attribute: 


CREATE OR REPLACE TYPE clob_typ AS OBJECT (c clob); 
/ 


Enable unpacked storage of the opaque data 
types XMLType and clob_typ in ANYDATA column x of table t1: 


ALTER TABLE t1 MODIFY OPAQUE TYPE x STORE (XMLType, 
clob_typ) UNPACKED; 


Insert XMLType and clob_typ objects into table t1. These types will use 
unpacked storage: 


INSERT INTO t1 
VALUES(1, anydata.convertobject(XMLType(‘<Test>This is test 
XML</Test>'))); 


INSERT INTO t1 
VALUES(2, anydata.convertobject(clob_typ(TO_CLOB(‘This is a 
test CLOB')))); 


Query table t1 to view the names of the types stored 
in ANYDATA column x: 


SELECT t1.*, anydata.getTypeName(t1.x) typename FROM t1; 


N X() TYPENAME 
1 ANYDATA() SYS.XMLTYPE 
2 ANYDATA() HR.CLOB_TYP 


Create functions that allow you to query the values stored in 
the XMLType and clob_typ data types: 


CREATE FUNCTION get_xmltype (ad IN ANYDATA) RETURN 
VARCHAR2 AS 
rtn_val PLS_INTEGER; 
my_xmltype XMLType; 
string val VARCHAR2(30); 
BEGIN 
rtn_val := ad.getObject(my_xmltype); 
string_val := my_xmltype.getstringval(); 
return (string_val); 
END; 
/ 


CREATE FUNCTION get_clob_typ (ad INANYDATA) RETURN 
VARCHAR2 AS 
rtn_val PLS_ INTEGER; 
my_clob_typ clob_typ; 
string val VARCHAR2(30); 
BEGIN 
rtn_val := ad.getObject(my_clob_typ); 
string_val := (my_clob_typ.c); 
return (string_val); 
END; 
/ 


Query table t1 to view the values stored in each data type 
in ANYDATA column x: 


SELECT t1.*, anydata.getTypeName(t1.x) typename, 
CASE 
WHEN anydata.gettypename(t1.x) = 'SYS.XMLTYPE' THEN 
get_xmltype(t1.x) 
WHEN anydata.gettypename(t1.x) = 'HR.CLOB_TYP' THEN 
get_clob_typ(t1.x) 
END string_value 


FROM t1; 
N XQ TYPENAME STRING_VALUE 
1 ANYDATAQ) SYS.XMLTYPE <Test>This is test 
XML</Test> 
2 ANYDATA() HR.CLOB_TYP This is a test CLOB 
DROP TABLE 


Use the DROP TABLE statement to move a table or object table to the 
recycle bin or to remove the table and all its data from the database entirely. 


For an external table, this statement removes only the table metadata in the 
database. It has no affect on the actual data, which resides outside of the 
database. 


When you drop a table that is part of a cluster, the table is moved to the 
recycle bin. However, if you subsequently drop the cluster, then the table is 
purged from the recycle bin and can no longer be recovered with 

a FLASHBACK TABLE operation. 


Dropping a table invalidates dependent objects and removes object 
privileges on the table. If you want to re-create the table, then you must 
regrant object privileges on the table, re-create the indexes, integrity 
constraints, and triggers for the table, and respecify its storage parameters. 
Truncating has none of these effects. Therefore, removing rows with 

the TRUNCATE statement can be more efficient than dropping and re- 
creating a table. 


The table must be in your own schema or you must have 
the DROP ANY TABLE system privilege. 


You can perform DDL operations (such 

as ALTER TABLE, DROP TABLE, CREATE INDEX) on a temporary table 
only when no session is bound to it. A session becomes bound to a 
temporary table by performing an INSERT operation on the table. A session 
becomes unbound to the temporary table by issuing 

a TRUNCATE statement or at session termination, or, for a transaction- 
specific temporary table, by issuing a COMMIT or ROLLBACK statement. 


You can drop a private temporary table using the 

existing DROP TABLE command. Dropping a private temporary table will 
not commit an existing transaction. This applies to both transaction-specific 
and session-specific private temporary tables. Note that a dropped private 
temporary table will not go into the RECYCLEBIN. 


Examples 
Dropping a Table: Example 


The following statement drops the oe.list_customers table. 
DROP TABLE list_customers PURGE; 


VIEW 


In Oracle, view is a virtual table that does not physically exist. It is stored in 
Oracle data dictionary and do not store any data. It can be executed when 
called. 


A view is created by a query joining one or more tables. 


CREATE VIEW 


Use the CREATE VIEW statement to define a view , which is a logical 
table based on one or more tables or views. A view contains no data itself. 
The tables upon which a view is based are called base tables . 


You can also create an object view or a relational view that supports 
LOBs, object types, REF data types, nested table, or varray types on top of 


the existing view mechanism. An object view is a view of a user-defined 
type, where each row contains objects, each object with a unique object 
identifier. 


You can also create XMLType views, which are similar to object views but 
display data from XMLSchema-based tables of XMLType. 


To create a view in your own schema, you must have 
the CREATE VIEW system privilege. To create a view in another user's 
schema, you must have the CREATE ANY VIEW system privilege. 


To create a subview, you must have the UNDER ANY VIEW system 
privilege or the UNDER object privilege on the superview. 


The owner of the schema containing the view must have the privileges 
necessary to either select (READ or SELECT privilege), insert, update, or 
delete rows from all the tables or views on which the view is based. The 
owner must be granted these privileges directly, rather than through a role. 


To use the basic constructor method of an object type when creating an 
object view, one of the following must be true: 


The object type must belong to the same schema as the view to be 
created. 
- You must have the EXECUTE ANY TYPE system privileges. 
You must have the EXECUTE object privilege on that object type. 
Examples 


Creating a View: Example 


The following statement creates a view of the sample 
table employees named emp_view. The view shows the employees in 
department 20 and their annual salary: 


CREATE VIEW emp_view AS 
SELECT last_name, salary*12 annual_salary 
FROM employees 
WHERE department_id = 20; 


The view declaration need not define a name for the column based on the 
expression salary*12, because the subquery uses a column alias 
(annual_salary) for this expression. 


Creating an Editioning View: Example 


The following statement creates an editioning view of the orders table: 


CREATE EDITIONING VIEW ed_orders_view (0_id, o_date, 
o_status) 
AS SELECT order_id, order_date, order_status FROM orders 
WITH READ ONLY; 


You can use this view to isolate an application from DDL changes to 

the orders table during an administrative operation such as an upgrade. You 
can create a DML trigger on this view, so that the trigger fires when a DML 
operation targets the view itself, but does not fire if the DML operation 
targets the orders table. 


Creating a View with Constraints: Example 


The following statement creates a restricted view of the sample 

table hr.employees and defines a unique constraint on the email view 
column and a primary key constraint for the view on the emp_id view 
column: 


CREATE VIEW emp_sal (emp_id, last_name, 
email UNIQUE RELY DISABLE NOVALIDATE, 
CONSTRAINT id_pk PRIMARY KEY (emp_id) RELY DISABLE 
NOVALIDATE) 
AS SELECT employee_id, last_name, email FROM employees; 


Creating an Updatable View: Example 


The following statement creates an updatable view named clerk of all clerks 
in the employees table. Only the employees' IDs, last names, department 
numbers, and jobs are visible in this view, and these columns can be 
updated only in rows where the employee is a kind of clerk: 


CREATE VIEW clerk AS 
SELECT employee_id, last_name, department_id, job_id 
FROM employees 
WHERE job_id = '"PU_CLERK' 
or job_id = 'SH_CLERK' 
or job_id = 'ST_CLERK'; 


This view lets you change the job_id of a purchasing clerk to purchasing 
manager (PU_MAN): 


UPDATE clerk SET job_id = 'PU_MAN' WHERE employee_id = 
118; 


The next example creates the same view WITH CHECK OPTION. You 
cannot subsequently insert a new row into clerk if the new employee is not 
a clerk. You can update an employee's job_id from one type of clerk to 
another type of clerk, but the update in the preceding statement would fail, 
because the view cannot access employees with non-clerk job_id. 


CREATE VIEW clerk AS 
SELECT employee_id, last_name, department_id, job_id 
FROM employees 
WHERE job_id = '"PU_CLERK' 
or job_id = 'SH_CLERK' 
or job_id = 'ST_CLERK' 
WITH CHECK OPTION; 


Creating a Join View: Example 


A join view is one whose view subquery contains a join. If at least one 
column in the join has a unique index, then it may be possible to modify 
one base table in a join view. You can 

query USER_UPDATABLE_COLUMNS to see whether the columns in a 
join view are updatable. For example: 


CREATE VIEW locations view AS 
SELECT d.department_id, d.department_name, |.location_id, l.city 
FROM departments d, locations | 
WHERE d.location_id = |.location_id; 


SELECT column_name, updatable 
FROM user_updatable_columns 
WHERE table_name = 'LOCATIONS_VIEW' 
ORDER BY column_name, updatable; 


COLUMN_NAME UPD 
DEPARTMENT_ID YES 
DEPARTMENT_NAME YES 
LOCATION_ID NO 

CITY NO 


In the preceding example, the primary key index on the location_id column 
of the locations table is not unique in the locations_view view. 

Therefore, locations is not a key-preserved table and columns from that 
base table are not updatable. 


INSERT INTO locations_view VALUES 
(999, ‘Entertainment’, 87, 'Roma'’); 
INSERT INTO locations_view VALUES 
Kk 
ERROR at line 1: 
ORA-01776: cannot modify more than one base table through a join 
view 


You can insert, update, or delete a row from the departments base table, 
because all the columns in the view mapping to the departments table are 
marked as updatable and because the primary key of departments is retained 
in the view. 


INSERT INTO locations_view (department_id, department_name) 
VALUES (999, 'Entertainment'); 


1 row created. 


Creating a Read-Only View: Example 


The following statement creates a read-only view named customer_ro of 
the oe.customers table. Only the customers’ last names, language, and credit 
limit are visible in this view: 


CREATE VIEW customer_ro (name, language, credit) 
AS SELECT cust_last_name, nls_language, credit_limit 
FROM customers 
WITH READ ONLY; 


Creating an Object View: Example 


The following example shows the creation of the type inventory_typ in 
the oc schema, and the oc_inventories view that is based on that type: 


CREATE TYPE inventory_typ 
OID '82A4AF6A4CD4656DE034080020E0EE3D' 


AS OBJECT 
( product_id NUMBER(6) 
, warehouse warehouse_typ 


, quantity_on_hand NUMBER(8) 
); 
/ 
CREATE OR REPLACE VIEW oc_inventories OF inventory_typ 
WITH OBJECT OID (product_id) 
AS SELECT i.product_id, 

warehouse_typ(w.warehouse_id, w.warehouse_name, 
w.location_id), 

i.quantity_on_hand 

FROM inventories i, warehouses w 


WHERE i.warehouse_id=w.warehouse_id; 


Creating a View on an XMLType Table: Example 


The following example builds a regular view on 
the XMLType table xwarehouses: 


CREATE VIEW warehouse_view AS 
SELECT VALUE(p) AS warehouse_xml 
FROM xwarehouses p; 


You select from such a view as follows: 


SELECT e.warehouse_xml.getclobval() 
FROM warehouse_view e 
WHERE EXISTSNODE(warehouse_xml, '//Docks') =1; 


Creating an XMLType View: Example 


In some cases you may have an object-relational table upon which you 


would like to build an XMLType view. The following example creates an 
object-relational table resembling the XMLType column warehouse_spec in 
the sample table oe.warehouses, and then creates an XMLType view of that 


table: 


CREATE TABLE warehouse_table 


( 
WarehouseID NUMBER, 
Area NUMBER, 
Docks NUMBER, 


DockType VARCHAR2(100), 
WaterAccess VARCHAR2(10), 
RailAccess VARCHAR2(10), 
Parking VARCHAR2(20), 
VClearance NUMBER 


); 


INSERT INTO warehouse_table 
VALUES(5, 103000,3,'Side Load','false’,'true'’,’Lot',15); 


CREATE VIEW warehouse_view OF XMLTYPE 
XMLSCHEMA "http://www.example.com/xwarehouses.xsd" 
ELEMENT "Warehouse" 
WITH OBJECT ID 
(extract((OBJECT_VALUE, 
'/Warehouse/Area/text()').getnumberval()) 
AS SELECT XMLELEMENT("Warehouse", 
XMLFOREST(WarehouselID as "Building", 
area as "Area", 
docks as "Docks", 
docktype as "DockType", 
wateraccess as "WaterAccess", 
railaccess as "RailAccess", 
parking as "Parking", 
VClearance as "VClearance")) 
FROM warehouse_table; 


You query this view as follows: 
SELECT VALUE(e) FROM warehouse_view e; 


ALTER VIEW 


Use the ALTER VIEW statement to explicitly recompile a view that is 
invalid or to modify view constraints. Explicit recompilation lets you locate 
recompilation errors before run time. You may want to recompile a view 
explicitly after altering one of its base tables to ensure that the alteration 
does not affect the view or other objects that depend on it. 


You can also use ALTER VIEW to define, modify, or drop view constraints. 


You cannot use this statement to change the definition of an existing view. 
Further, if DDL changes to the view's base tables invalidate the view, then 
you cannot use this statement to compile the invalid view. In these cases, 


you must redefine the view using CREATE VIEW with 
the OR REPLACE keywords. 


When you issue an ALTER VIEW statement, Oracle Database recompiles 
the view regardless of whether it is valid or invalid. The database also 
invalidates any local objects that depend on the view. 


If you alter a view that is referenced by one or more materialized views, 
then those materialized views are invalidated. Invalid materialized views 
cannot be used by query rewrite and cannot be refreshed. 


The view must be in your own schema or you must 
have ALTER ANY TABLE system privilege. 


Examples 
Altering a View: Example 


To recompile the view customer_ro, issue the following statement: 


ALTER VIEW customer_ro 
COMPILE; 


If Oracle Database encounters no compilation errors while 

recompiling customer_ro, then customer_ro becomes valid. If recompiling 
results in compilation errors, then the database returns an error 

and customer_ro remains invalid. 


Oracle Database also invalidates all dependent objects. These objects 
include any procedures, functions, package bodies, and views that 
reference customer_ro. If you subsequently reference one of these objects 
without first explicitly recompiling it, then the database recompiles it 
implicitly at run time. 

DROP VIEW 

Use the DROP VIEW statement to remove a view or an object view from 


the database. You can change the definition of a view by dropping and re- 
creating it. 


The view must be in your own schema or you must have 
the DROP ANY VIEW system privilege. 


Examples 
Dropping a View: Example 


The following statement drops the emp_view view: 
DROP VIEW emp_view; 


MATERIALIZED VIEW 


A materialized view in Oracle is a database object that contains the results 
of a query. They are local copies of data located remotely, or are used to 
create summary tables based on aggregations of a table's data. Materialized 
views, which store data based on remote tables are also, know as snapshots. 


A materialized view can query tables, views, and other materialized views. 
Collectively these are called master tables (a replication term) or detail 
tables (a data warehouse term). 


CREATE MATERIALIZED VIEW 


Use the CREATE MATERIALIZED VIEW statement to create a 
materialized view . A materialized view is a database object that contains 
the results of a query. The FROM clause of the query can name tables, 
views, and other materialized views. Collectively these objects are called 
master tables (a replication term) or detail tables (a data warehousing 
term). This reference uses "master tables" for consistency. The databases 
containing the master tables are called the master databases . 


For replication purposes, materialized views allow you to maintain read- 
only copies of remote data on your local node. You can select data from a 
materialized view as you would from a table or view. In replication 
environments, the materialized views commonly created are primary key 
, rowid, object , and subquery materialized views. 


For data warehousing purposes, the materialized views commonly created 
are materialized aggregate views , single-table materialized aggregate 
views , and materialized join views . All three types of materialized views 
can be used by query rewrite, an optimization technique that transforms a 


user request written in terms of master tables into a semantically equivalent 
request that includes one or more materialized views. 


The privileges required to create a materialized view should be granted 
directly rather than through a role. 


To create a materialized view in your own schema: 


You must have been granted 
the CREATE MATERIALIZED VIEW system privilege and either 
the CREATE TABLE or CREATE ANY TABLE system privilege. 


You must also have access to any master tables of the materialized 
view that you do not own, either through a READ or SELECT object 
privilege on each of the tables or through 

the READ ANY TABLE or SELECT ANY TABLE system privilege. 


To create a materialized view in another user's schema: 


You must have the CREATE ANY MATERIALIZED VIEW system 
privilege. 

- The owner of the materialized view must have 
the CREATE TABLE system privilege. The owner must also have 
access to any master tables of the materialized view that the schema 
owner does not own (for example, if the master tables are on a remote 
database) and to any materialized view logs defined on those master 
tables, either through a READ or SELECT object privilege on each of 
the tables or through 
the READ ANY TABLE or SELECT ANY TABLE system privilege. 


To create a refresh-on-commit materialized view 

(REFRESH ON COMMIT clause), in addition to the preceding privileges, 
you must have the ON COMMIT REFRESH object privilege on any master 
tables that you do not own or you must have 

the ON COMMIT REFRESH system privilege. 


To create the materialized view with query rewrite enabled , in addition 
to the preceding privileges: 


If the schema owner does not own the master tables, then the schema 
owner must have the GLOBAL QUERY REWRITE privilege or 


the QUERY REWRITE object privilege on each table outside the 
schema. 


If you are defining the materialized view on a prebuilt container 
(ON PREBUILT TABLE clause), then you must have 

the READ or SELECT privilege WITH GRANT OPTION on the 
container table. 


The user whose schema contains the materialized view must have sufficient 
quota in the target tablespace to store the master table and index of the 
materialized view or must have the UNLIMITED TABLESPACE system 
privilege. 

When you create a materialized view, Oracle Database creates one internal 
table and at least one index, and may create one view, all in the schema of 
the materialized view. Oracle Database uses these objects to maintain the 
materialized view data. You must have the privileges necessary to create 
these objects. 


You can create the following types of local materialized views (including 
both ON COMMIT and ON DEMAND) on master tables with commit 
SCN-based materialized view logs: 


Materialized aggregate views, including materialized aggregate views 
on a single table 

e Materialized join views 
Primary-key-based and rowid-based single table materialized views 
UNION ALL materialized views, where each UNION ALL branch is 
one of the above materialized view types 


You cannot create remote materialized views on master tables with commit 
SCN-based materialized view logs. 


Creating a materialized view on master tables with different types of 
materialized view logs (that is, a master table with timestamp-based 
materialized view logs and a master table with commit SCN-based 
materialized view logs) is not supported and causes ORA-32414. 


To specify an edition in the evaluation_edition_clause or the 
unusable_editions_clause , you must have the USE privilege on the edition. 


Examples 


Creating a Simple Materialized View: Example 


The following statement creates a very simple materialized view based on 
the employees and table in the hr schema: 


CREATE MATERIALIZED VIEW mv1 AS SELECT * FROM 
hr.employees; 


By default, Oracle Database creates a primary key materialized view with 
refresh on demand only. If a materialized view log exists on employees, 
then mv1 can be altered to be capable of fast refresh. If no such log exists, 
then only full refresh of mv1 is possible. Oracle Database uses default 
storage properties for mv1. The only privileges required for this operation 
are the CREATE MATERIALIZED VIEW system privilege, and 

the READ or SELECT object privilege on hr.employees. 


Creating Subquery Materialized Views: Example 


The following statement creates a subquery materialized view based on 
the customers and countries tables in the sh schema at the remote database: 


CREATE MATERIALIZED VIEW foreign_customers 
AS SELECT * FROM sh.customers@remote cu 
WHERE EXISTS 

(SELECT * FROM sh.countries@remote co 
WHERE co.country_id = cu.country_id); 


Creating Materialized Aggregate Views: Example 


The following statement creates and populates a materialized aggregate 
view on the sample sh.sales table and specifies the default refresh method, 
mode, and time. 


CREATE MATERIALIZED VIEW LOG ON times 
WITH ROWID, SEQUENCE (time_id, calendar_year) 
INCLUDING NEW VALUES; 


CREATE MATERIALIZED VIEW LOG ON products 


WITH ROWID, SEQUENCE (prod_id) 
INCLUDING NEW VALUES; 


CREATE MATERIALIZED VIEW sales_mv 

BUILD IMMEDIATE 

REFRESH FAST ON COMMIT 

AS SELECT t.calendar_year, p.prod_id, 
SUM(s.amount_sold) AS sum_sales 
FROM times t, products p, sales s 
WHERE t.time_id = s.time_id AND p.prod_id = s.prod_id 
GROUP BY t.calendar_year, p.prod_id; 


Creating Materialized Join Views: Example 


The following statement creates and populates the materialized aggregate 
view sales_by_month_by_state using tables in the sample sh schema. The 
materialized view will be populated with data as soon as the statement 
executes successfully. By default, subsequent refreshes will be 
accomplished by reexecuting the defining query of the materialized view: 


CREATE MATERIALIZED VIEW sales_by_month_by_state 

TABLESPACE example 

PARALLEL 4 

BUILD IMMEDIATE 

REFRESH COMPLETE 

ENABLE QUERY REWRITE 

AS SELECT t.calendar_month_desc, c.cust_state_province, 
SUM(s.amount_sold) AS sum_sales 
FROM times t, sales s, customers c 
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id 
GROUP BY t.calendar_month_desc, c.cust_state_province; 


Creating Prebuilt Materialized Views: Example 


The following statement creates a materialized aggregate view for the 
preexisting summary table, sales_sum_table: 


CREATE TABLE sales_sum_table 
(month VARCHAR2(8), state VARCHAR2(40), sales 
NUMBER(10,2)); 


CREATE MATERIALIZED VIEW sales_sum_table 
ON PREBUILT TABLE WITH REDUCED PRECISION 
ENABLE QUERY REWRITE 
AS SELECT t.calendar_month_desc AS month, 
c.cust_state_province AS state, 
SUM(s.amount_sold) AS sales 
FROM times t, customers c, sales s 
WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id 
GROUP BY t.calendar_month_desc, c.cust_state_province; 


In the preceding example, the materialized view has the same name and 
also has the same number of columns with the same data types as the 
prebuilt table. The WITH REDUCED PRECISION clause allows for 
differences between the precision of the materialized view columns and the 
precision of the values returned by the subquery. 


Creating Primary Key Materialized Views: Example 


The following statement creates the primary key materialized 
view catalog on the sample table oe.product_information: 


CREATE MATERIALIZED VIEW catalog 

REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 
1/4096 

WITH PRIMARY KEY 

AS SELECT * FROM product_information; 


Creating Rowid Materialized Views: Example 


The following statement creates a rowid materialized view on the sample 
table oe.orders: 


CREATE MATERIALIZED VIEW order_data REFRESH WITH 
ROWID 
AS SELECT * FROM orders; 


Periodic Refresh of Materialized Views: Example 


The following statement creates the primary key materialized 
view emp_data and populates it with data from the sample 
table hr.employees: 


CREATE MATERIALIZED VIEW LOG ON employees 
WITH PRIMARY KEY 
INCLUDING NEW VALUES; 


CREATE MATERIALIZED VIEW emp_data 
PCTFREE 5 PCTUSED 60 
TABLESPACE example 
STORAGE (INITIAL 50K) 
REFRESH FAST NEXT sysdate + 7 
AS SELECT * FROM employees; 


The preceding statement does not include a START WITH parameter, so 
Oracle Database determines the first automatic refresh time by evaluating 
the NEXT value using the current SYSDATE. A materialized view log was 
created for the employee table, so Oracle Database performs a fast refresh 
of the materialized view every 7 days, beginning 7 days after the 
materialized view is created. 


Because the materialized view conforms to the conditions for fast refresh, 
the database will perform a fast refresh. The preceding statement also 
establishes storage characteristics that the database uses to maintain the 
materialized view. 


Automatic Refresh Times for Materialized Views: Example 


The following statement creates the complex materialized 
view all_customers that queries the employee tables on 


the remote and local databases: 


CREATE MATERIALIZED VIEW all_customers 
PCTFREE 5 PCTUSED 60 
TABLESPACE example 
STORAGE (INITIAL 50K) 
USING INDEX STORAGE (INITIAL 25K) 
REFRESH START WITH ROUND(SYSDATE + 1) + 11/24 
NEXT NEXT_DAY(TRUNC(SYSDATE), 'MONDAY'’) + 15/24 
AS SELECT * FROM sh.customers@remote 
UNION 
SELECT * FROM sh.customers@local; 


Oracle Database automatically refreshes this materialized view tomorrow at 
11:00 a.m. and subsequently every Monday at 3:00 p.m. The default refresh 
method is FORCE. The defining query contains a UNION operator, which 
is not supported for fast refresh, so the database will automatically perform 
a complete refresh. 


The preceding statement also establishes storage characteristics for both the 
materialized view and the index that the database uses to maintain it: 


- The first STORAGE clause establishes the sizes of the first and 
second extents of the materialized view as 50 kilobytes each. 


The second STORAGE clause, appearing with 
the USING INDEX clause, establishes the sizes of the first and 
second extents of the index as 25 kilobytes each. 


Creating a Fast Refreshable Materialized View: Example 


The following statement creates a fast-refreshable materialized view that 
selects columns from the order_items table in the sample oe schema, using 
the UNION set operator to restrict the rows returned from 

the product_information and inventories tables using WHERE conditions. 
The materialized view logs for order_items and product_information were 
created in the "Examples" section 

of CREATE MATERIALIZED VIEW LOG. This example also requires a 
materialized view log on oe.inventories. 


CREATE MATERIALIZED VIEW LOG ON inventories 
WITH (quantity_on_hand); 


CREATE MATERIALIZED VIEW warranty_orders REFRESH FAST 
AS 
SELECT order_id, line_item_id, product_id FROM order_items o 
WHERE EXISTS 
(SELECT * FROM inventories i WHERE o.product_id = 
i.product_id 
AND i.quantity_on_hand IS NOT NULL) 
UNION 
SELECT order_id, line_item_id, product_id FROM order_items 
WHERE quantity > 5; 


The materialized view warranty_orders requires that materialized view logs 
be defined on order_items (with product_id as a join column) and on 
inventories (with quantity_on_hand as a filter column). 


Creating a Nested Materialized View: Example 


The following example uses the materialized view from the preceding 
example as a master table to create a materialized view tailored for a 
particular sales representative in the sample oe schema: 


CREATE MATERIALIZED VIEW my_warranty_orders 
AS SELECT w.order_id, w.line_item_id, o.order_date 
FROM warranty_orders w, orders o 
WHERE o.order_id = o.order_id 
AND o.sales_rep_id = 165; 


CREATE MATERIALIZED VIEW LOG 


Use the CREATE MATERIALIZED VIEW LOG statement to create a 
materialized view log , which is a table associated with the master table of 
a materialized view. 


Materialized view logs are used for two types of materialized view 
refreshes: fast refresh and synchronous refresh. 


Fast refresh uses a conventional materialized view log. During a fast 
refresh (also called an incremental refresh), when DML changes are made 
to master table data, Oracle Database stores rows describing those changes 
in the materialized view log and then uses the materialized view log to 
refresh materialized views based on the master table. 


Synchronous refresh uses a special type of materialized view log called 
a staging log . During a synchronous refresh, DML changes are first 
described in the staging log and then applied to the master tables and the 
materialized views simultaneously. This guarantees that the master table 
data and materialized view data are in sync throughout the refresh process. 
This refresh method is useful in data warehousing environments. 


Without a materialized view log, Oracle Database must reexecute the 
materialized view query to refresh the materialized view. This process is 
called a complete refresh . Usually, a complete refresh takes more time to 
complete than a fast refresh or a synchronous refresh. 


A materialized view log is located in the master database in the same 
schema as the master table. A master table can have only one materialized 
view log defined on it. 


To fast refresh or synchronous refresh a materialized join view, you must 
create a materialized view log for each of the tables referenced by the 
materialized view. 


Fast refresh supports two types of materialized view logs: timestamp-based 
materialized view logs and commit SCN-based materialized view logs. 
Timestamp-based materialized view logs use timestamps and require some 
setup operations when preparing to refresh the materialized view. Commit 
SCN-based materialized view logs use commit SCN data rather than 
timestamps, which removes the need for the setup operations and thus can 
improve the speed of the materialized view refresh. If you specify 

the COMMIT SCN clause, then a commit SCN-based materialized view log 
is created. Otherwise, a time-stamp based materialized view log is created. 
Note that only new materialized view logs can take advantage 

of COMMIT SCN. Existing materialized view logs cannot be altered to 
add COMMIT SCN unless they are dropped and recreated. 


Synchronous refresh supports only timestamp-based staging logs. 


The privileges required to create a materialized view log directly relate to 
the privileges necessary to create the underlying objects associated with a 
materialized view log. 


- If you own the master table, then you can create an associated 
materialized view log if you have the CREATE TABLE privilege. 


If you are creating a materialized view log for a table in another user's 
schema, then you must have 

the CREATE ANY TABLE and COMMENT ANY TABLE system 
privileges, as well as either the READ or SELECT object privilege on 
the master table or 

the READ ANY TABLE or SELECT ANY TABLE system privilege. 


In either case, the owner of the materialized view log must have sufficient 
quota in the tablespace intended to hold the materialized view log or must 
have the UNLIMITED TABLESPACE system privilege. 


Examples 
Creating a Materialized View Log for Fast Refresh: Examples 


The following statement creates a materialized view log on 
the oe.customers table that specifies physical and storage characteristics: 


CREATE MATERIALIZED VIEW LOG ON customers 
PCTFREE 5 
TABLESPACE example 
STORAGE (INITIAL 10K); 


The materialized view log on customers supports fast refresh for primary 
key materialized views only. 


The following statement creates another version of the materialized view 
log with the ROWID clause, which enables fast refresh for more types of 
materialized views: 


CREATE MATERIALIZED VIEW LOG ON customers WITH 
PRIMARY KEY, ROWID; 


This materialized view log on customers makes fast refresh possible for 
rowid materialized views and for materialized join views. To provide for 
fast refresh of materialized aggregate views, you must also specify 

the SEQUENCE and INCLUDING NEW VALUES clauses, as shown in 
the example that follows. 


Specify a Purge Repeat Interval for a Materialized View Log: Example 


The following statement creates a materialized view log on 

the oe.orders table. The contents of the log will be purged once every five 
days, beginning five days after the creation date of the materialized view 
log: 


CREATE MATERIALIZED VIEW LOG ON orders 
PCTFREE 5 
TABLESPACE example 
STORAGE (INITIAL 10K) 
PURGE REPEAT INTERVAL '5' DAY; 


Specifying Filter Columns for Materialized View Logs: Example 


CREATE MATERIALIZED VIEW LOG ON sales 
WITH ROWID, SEQUENCE(amount_sold, time_id, prod_id) 
INCLUDING NEW VALUES; 


Specifying Join Columns for Materialized View Logs: Example 


The following statement creates a materialized view log on 
the order_items table of the sample oe schema. The log records primary 
keys and product_id. 


CREATE MATERIALIZED VIEW LOG ON order_items WITH 
(product_id); 


Including New Values in Materialized View Logs: Example 


The following example creates a materialized view log on 
the oe.product_information table that 
specifies INCLUDING NEW VALUES: 


CREATE MATERIALIZED VIEW LOG ON product_information 
WITH ROWID, SEQUENCE (list_price, min_price, category_id), 
PRIMARY KEY 
INCLUDING NEW VALUES; 


You could create the following materialized aggregate view to use 
the product_information log: 


CREATE MATERIALIZED VIEW products_mv 
REFRESH FAST ON COMMIT 
AS SELECT SUM(list_price - min_price), category_id 
FROM product_information 
GROUP BY category_id; 


This materialized view is eligible for fast refresh because the log defined on 
its master table includes both old and new values. 


Creating a Staging Log for Synchronous Refresh: Example 


The following statement creates a staging log on the sh.sales fact table. The 
staging log is named mystage_log and is stored in the sh schema. It can be 
used for synchronous refresh. 


CREATE MATERIALIZED VIEW LOG ON sales 
PCTFREE 5 
TABLESPACE example 
STORAGE (INITIAL 10K) 
FOR SYNCHRONOUS REFRESH USING mystage_log: 


CREATE MATERIALIZED ZONEMAP 


Use the CREATE MATERIALIZED ZONEMAP statement to create a zone 
map. 


A zone map is a special type of materialized view that stores information 
about zones. A zone is a set of contiguous data blocks on disk that stores 
the values of one or more table columns. Multiple zones are usually 
required to store all of the values of the table columns. A zone map tracks 
the minimum and maximum table column values stored in each zone. 


Zone maps enable you to reduce the I/O and CPU costs of table scans. 
When a SQL statement contains predicates on columns in a zone map, the 
database compares the predicate values to the minimum and maximum 
table column values stored in each zone to determine which zones to read 
during SQL execution. 


Oracle Database supports the following types of zone maps: 


- A basic zone map is defined on a single table and maintains zone 
information for specified columns in that table. 


You can create a basic zone map either by specifying the 
create_zonemap_on_table clause, or by specifying the 
create_zonemap_as_subquery clause where the FROM clause of the 
defining subquery specifies a single table. 


- A join zone map is defined on two or more joined tables and 
maintains zone information for specified columns in any of the joined 
tables. 


You can create a join zone map by specifying the 
create_zonemap_as_subquery clause. The FROM clause of the 
defining subquery must specify a table that is left outer joined with 
one or more other tables. 


Zone maps are commonly used with star schemas in data warehousing 
environments. However, a star schema is not a requirement for creating a 
zone map. In either case, this reference uses star schema terminology to 
refer to the tables in a zone map. In a join zone map, the outer table of the 
join(s) is referred to as the fact table , and the tables with which this table 
is joined are referred to as dimension tables . Collectively these tables 
are called the base tables of the zone map. In a basic zone map, the 
single table on which the zone map is defined is referred to as both the fact 
table and the base table of the zone map. 


A base table of a zone map can be a partitioned or composite-partitioned 
table. In this case, the zone map maintains minimum and maximum column 
values for each partition (and subpartition) as well as for each zone. 


You can create zone maps for use with or without attribute clustering: 


To create a zone map for use with attribute clustering, use either of the 
following methods: 
o Use the CREATE MATERIALIZED ZONEMAP statement and 
include attribute clustered columns in the zone map. 


o Specify the WITH MATERIALIZED ZONEMAP clause while 
creating or modifying an attribute clustered table. 


To create a zone map for use without attribute clustering, use 
the CREATE MATERIALIZED ZONEMAP statement and include 
columns that are not attribute clustered in the zone map. 


To create a zone Map in your own schema: 


You must have the CREATE MATERIALIZED VIEW system 
privilege and either 
the CREATE TABLE or CREATE ANY TABLE system privilege. 


You must have access to any base tables of the zone map that you do 

not own, either through a READ or SELECT object privilege on each 
of the tables or through 

the READ ANY TABLE or SELECT ANY TABLE system privilege. 


To create a zone map in another user's schema: 


You must have the CREATE ANY MATERIALIZED VIEW system 
privilege. 

The owner of the zone map must have the CREATE TABLE system 
privilege. The owner must also have access to any base tables of the 
zone map that the schema owner does not own, either through 

a READ or SELECT object privilege on each of the tables or through 
the READ ANY TABLE or SELECT ANY TABLE system privilege. 


To create a refresh-on-commit zone map 

(REFRESH ON COMMIT clause), in addition to the preceding privileges, 
you must have the ON COMMIT REFRESH object privilege on any base 
tables that you do not own or you must have 


the ON COMMIT REFRESH system privilege. Unlike materialized views, 
you can create a refresh-on-commit zone map even if there are no 
materialized view logs on the base tables. 


When you create a zone map, Oracle Database creates one internal table 
and at least one index, all in the schema of the zone map. Oracle Database 
uses these objects to maintain the zone map data. You must have the 
privileges necessary to create these objects, and you must have sufficient 
quota in the target tablespace to store these objects or you must have 

the UNLIMITED TABLESPACE system privilege. 


Examples 


The following statement creates a basic zone map called sales_zmap. The 
zone map tracks columns cust_id and prod_id in the table sales. 


CREATE MATERIALIZED ZONEMAP sales_zmap 
ON sales(cust_id, prod_id); 


The following statement creates a basic zone map called sales_zmap that is 
similar to the zone map created in the previous example. However, this 
statement uses a defining subquery to create the zone map. 


CREATE MATERIALIZED ZONEMAP sales_zmap 
AS SELECT SYS_OP_ZONE_ID(rowid), 
MIN(cust_id), MAX(cust_id), 
MIN(prod_id), MAX(prod_id) 
FROM sales 
GROUP BY SYS_OP_ZONE_ID(rowid); 


The following statement creates a join zone map called sales_zmap. The 
fact table for the zone map is sales and the zone map has one dimension 
table: customers. The zone map tracks two columns in the dimension 
table: cust_state_province and cust_city. 


CREATE MATERIALIZED ZONEMAP sales_zmap 
AS SELECT SYS_OP_ZONE_ID(s.rowid), 


MIN(cust_state_province), MAX(cust_state_province), 
MIN(cust_city), MAX(cust_city) 
FROM sales s 
LEFT OUTER JOIN customers c ON s.cust_id = c.cust_id 
GROUP BY SYS_OP_ZONE_ID(s.rowid); 


The following statement creates a join zone map called sales_zmap. The 
fact table for the zone map is sales and the zone map has two dimension 
tables: products and customers. The zone map tracks five columns in the 
dimension tables: prod_category and prod_subcategory in 

the products table, and country_id, cust_state_province, and cust_city in 
the customers table. 


CREATE MATERIALIZED ZONEMAP sales_zmap 
AS SELECT SYS_OP_ZONE_ID(s.rowid), 
MIN(prod_category), MA X(prod_category), 
MIN(prod_subcategory), MAX(prod_subcategory), 
MIN(country_id), MAX(country_id), 
MIN(cust_state_province), MAX(cust_state_province), 
MIN(cust_city), MAX(cust_city) 
FROM sales s 
LEFT OUTER JOIN products p ON s.prod_id = p.prod_id 
LEFT OUTER JOIN customers c ON s.cust_id = c.cust_id 
GROUP BY sys_op_zone_id(s.rowid); 


The following statement creates a join zone map that is identical to the zone 
map created in the previous example. The only difference is that the 
previous example uses the LEFT OUTER JOIN syntax in the FROM clause 
and the following example uses the outer join operator (+) in 

the WHERE clause. 


CREATE MATERIALIZED ZONEMAP sales_zmap 
AS SELECT SYS_OP_ZONE_ID(s.rowid), 
MIN(prod_category), MA X(prod_category), 
MIN(prod_subcategory), MAX(prod_subcategory), 
MIN(country_id), MAX(country_id), 


MIN(cust_state_province), MAX(cust_state_province), 
MIN(cust_city), MAX(cust_city) 

FROM sales s, products p, customers c 

WHERE s.prod_id = p.prod_id(+) AND 
s.cust_id = c.cust_id(+) 

GROUP BY sys_op_zone_id(s.rowid); 


ALTER MATERIALIZED VIEW 


A materialized view is a database object that contains the results of a query. 
The FROM clause of the query can name tables, views, and other 
materialized views. Collectively these source objects are called master 
tables (a replication term) or detail tables (a data warehousing term). 
This reference uses the term master tables for consistency. The databases 
containing the master tables are called the master databases . 


Use the ALTER MATERIALIZED VIEW statement to modify an existing 
materialized view in one or more of the following ways: 
- To change its storage characteristics 
To change its refresh method, mode, or time 
To alter its structure so that it is a different type of materialized view 
To enable or disable query rewrite 


The materialized view must be in your own schema, or you must have 
the ALTER ANY MATERIALIZED VIEW system privilege. 


To enable a materialized view for query rewrite: 


- If all of the master tables in the materialized view are in your schema, 
then you must have the QUERY REWRITE privilege. 


If any of the master tables are in another schema, then you must have 
the GLOBAL QUERY REWRITE privilege. 


- Ifthe materialized view is in another user's schema, then both you and 
the owner of that schema must have the 
appropriate QUERY REWRITE privilege, as described in the 
preceding two items. In addition, the owner of the materialized view 
must have SELECT access to any master tables that the materialized 
view owner does not own. 


To specify an edition in the evaluation_edition_clause or the 
unusable_editions_clause , you must have the USE privilege on the edition. 


Examples 
Automatic Refresh: Examples 


The following statement changes the default refresh method for 
the sales_by_month_by_state materialized view to FAST: 


ALTER MATERIALIZED VIEW sales_by_month_by_state 
REFRESH FAST; 


The next automatic refresh of the materialized view will be a fast refresh 
provided it is a simple materialized view and its master table has a 
materialized view log that was created before the materialized view was 
created or last refreshed. 


Because the REFRESH clause does not 

specify START WITH or NEXT values, Oracle Database will use the 
refresh intervals established by the REFRESH clause when 

the sales_by_month_by_state materialized view was created or last altered. 


The following statement establishes a new interval between automatic 
refreshes for the sales_by_month_by_state materialized view: 


ALTER MATERIALIZED VIEW sales_by_month_by_state 
REFRESH NEXT SYSDATE+7; 


Because the REFRESH clause does not specify a START WITH value, the 
next automatic refresh occurs at the time established by 

the START WITH and NEXT values specified when 

the sales_by_month_by_state materialized view was created or last altered. 


At the time of the next automatic refresh, Oracle Database refreshes the 
materialized view, evaluates the NEXT expression SYSDATE+7 to 
determine the next automatic refresh time, and continues to refresh the 
materialized view automatically once a week. Because 

the REFRESH clause does not explicitly specify a refresh method, Oracle 


Database continues to use the refresh method specified by 
the REFRESH clause of the CREATE MATERIALIZED VIEW or most 
recent ALTER MATERIALIZED VIEW statement. 


CONSIDER FRESH: Example 


The following statement instructs Oracle Database that materialized 

view sales_by_month_by_state should be considered fresh. This statement 
allows sales_by_month_by_state to be eligible for query rewrite 

in TRUSTED mode even after you have performed partition maintenance 
operations on the master tables of sales_by_month_by_ state: 


ALTER MATERIALIZED VIEW sales_by_month_by_state 
CONSIDER FRESH; 


As a result of the preceding statement, any partition maintenance operations 
that were done to the base table since the last refresh of the materialized 
view will not be applied to the materialized view. For example, the add, 
drop, or change of data in a partition in the base table will not be reflected 
in the materialized view if CONSIDER FRESH is used before the next 
refresh of the materialized view. 


Complete Refresh: Example 


The following statement specifies a new refresh method, a 
new NEXT refresh time, and a new interval between automatic refreshes of 
the emp_data materialized view: 


ALTER MATERIALIZED VIEW emp_data 
REFRESH COMPLETE 
START WITH TRUNC(SYSDATE+1) + 9/24 
NEXT SYSDATE*+7; 


The START WITH value establishes the next automatic refresh for the 
materialized view to be 9:00 a.m. tomorrow. At that point, Oracle Database 
performs a complete refresh of the materialized view, evaluates 

the NEXT expression, and subsequently refreshes the materialized view 
every week. 


Enabling Query Rewrite: Example 


The following statement enables query rewrite on the materialized 
view emp_data and implicitly revalidates it: 


ALTER MATERIALIZED VIEW emp_data 
ENABLE QUERY REWRITE; 


Primary Key Materialized View: Example 


The following statement changes the rowid materialized view order_data to 
a primary key materialized view. This example requires that you have 
already defined a materialized view log with a primary key on order_data. 


ALTER MATERIALIZED VIEW order_data 
REFRESH WITH PRIMARY KEY; 


Compiling a Materialized View: Example 


The following statement revalidates the materialized view store_mv: 
ALTER MATERIALIZED VIEW order_data COMPILE; 


ALTER MATERIALIZED VIEW LOG 


A materialized view log is a table associated with the master table of a 
materialized view. Use 

the ALTER MATERIALIZED VIEW LOG statement to alter the storage 
characteristics or type of an existing materialized view log. 


You must be the owner of the master table, or you must have 
the READ or SELECT privilege on the master table and 
the ALTER privilege on the materialized view log. 


FORCE 


If you specify FORCE and any items specified with the ADD clause have 
already been specified for the materialized view log, then Oracle Database 
does not return an error, but silently ignores the existing elements and adds 


to the materialized view log any items that do not already exist in the log. 
Likewise, if you specify INCLUDING NEW VALUES and that attribute 
has already been specified for the materialized view log, Oracle Database 
ignores the redundancy and does not return an error. 


Examples 
Rowid Materialized View Log: Example 


The following statement alters an existing primary key materialized view 
log to also record rowid information: 


ALTER MATERIALIZED VIEW LOG ON order_items ADD 
ROWID; 


Materialized View Log EXCLUDING NEW VALUES: Example 


The following statement alters the materialized view log 

on hr.employees by adding a filter column and excluding new values. Any 
materialized aggregate views that use this log will no longer be fast 
refreshable. However, if fast refresh is no longer needed, this action avoids 
the overhead of recording new values: 


ALTER MATERIALIZED VIEW LOG ON employees 
ADD (commission_pct) 
EXCLUDING NEW VALUES; 


ALTER MATERIALIZED ZONEMAP 


Use the ALTER MATERIALIZED ZONEMAP statement to modify an 
existing zone map in one of the following ways: 
To change its attributes 
- To change its default refresh method and mode 
To enable or disable its use for pruning 
- To compile it, rebuild it, or make it unusable 


The zone map must be in your own schema or you must have 
the ALTER ANY MATERIALIZED VIEW system privilege. 


The user who owns the schema containing the zone map must have access 
to any base tables of the zone map that reside outside of that schema, either 
through a READ or SELECT object privilege on each of the tables, or 
through the READ ANY TABLE or SELECT ANY TABLE system 
privilege. 


Examples 
Modifying Zone Map Attributes: Example 


The following statement modifies the PCTFREE and PCTUSED attributes 
of zone map sales_zmap, and modifies the zone map so that it does not use 
caching: 


ALTER MATERIALIZED ZONEMAP sales_zmap 
PCTFREE 20 PCTUSED 50 NOCACHE; 


Modifying the Default Refresh Method and Mode for a Zone Map: 
Example 


The following statement changes the default refresh method to FAST and 
the default refresh mode to ON COMMIT for zone map sales_zmap: 


ALTER MATERIALIZED ZONEMAP sales_zmap 
REFRESH FAST ON COMMIT; 


Disabling Use of a Zone Map for Pruning: Example 


The following statement disables use of zone map sales_zmap for pruning: 


ALTER MATERIALIZED ZONEMAP sales_zmap 
DISABLE PRUNING; 


Compiling a Zone Map: Example 


The following statement compiles zone map sales_zmap: 


ALTER MATERIALIZED ZONEMAP sales_zmap 


COMPILE; 


Rebuilding a Zone Map: Example 


The following statement rebuilds zone map sales_zmap: 


ALTER MATERIALIZED ZONEMAP sales_zmap 
REBUILD; 


Making a Zone Map Unusable: Example 


The following statement makes zone map sales_zmap unusable: 


ALTER MATERIALIZED ZONEMAP sales_zmap 
UNUSABLE; 


DROP MATERIALIZED VIEW 


Use the DROP MATERIALIZED VIEW statement to remove an existing 
materialized view from the database. 


When you drop a materialized view, Oracle Database does not place it in 
the recycle bin. Therefore, you cannot subsequently either purge or undrop 
the materialized view. 


The materialized view must be in your own schema or you must have 

the DROP ANY MATERIALIZED VIEW system privilege. You must also 
have the privileges to drop the internal table, views, and index that the 
database uses to maintain the materialized view data. 


Examples 
Dropping a Materialized View: Examples 


The following statement drops the materialized view emp_data in the 
sample schema hr: 


DROP MATERIALIZED VIEW emp_data; 


The following statement drops the sales_by_month_by_state materialized 
view and the underlying table of the materialized view, unless the 
underlying table was registered in 

the CREATE MATERIALIZED VIEW statement with 

the ON PREBUILT TABLE clause: 


DROP MATERIALIZED VIEW sales_by_month_by_state; 


DROP MATERIALIZED VIEW LOG 


Use the DROP MATERIALIZED VIEW LOG statement to remove a 
materialized view log from the database. 


To drop a materialized view log, you must have the privileges needed to 
drop a table. 


Examples 
Dropping a Materialized View Log: Example 


The following statement drops the materialized view log on 
the oe.customers master table: 


DROP MATERIALIZED VIEW LOG ON customers; 


DROP MATERIALIZED ZONEMAP 


Use the DROP MATERIALIZED ZONEMAP statement to remove an 
existing zone map from the database. 


The zone map must be in your own schema or you must have 

the DROP ANY MATERIALIZED VIEW system privilege. You must also 
have the privileges to drop the internal table and indexes that the database 
uses to maintain the zone map data. 


Example 
Dropping a Zone Map: Examples 


The following statement drops the zone map sales_zmap: 


DROP MATERIALIZED ZONEMAP sales_zmap; 


DIMENSION 


Use the CREATE DIMENSION statement to create a dimension . A 
dimension defines a parent-child relationship between pairs of column sets, 
where all the columns of a column set must come from the same table. 
However, columns in one column set (called a level ) can come from a 
different table than columns in another set. The optimizer uses these 
relationships with materialized views to perform query rewrite . The SQL 
Access Advisor uses these relationships to recommend creation of specific 
materialized views. 


CREATE DIMENSION 


To create a dimension in your own schema, you must have 

the CREATE DIMENSION system privilege. To create a dimension in 
another user's schema, you must have 

the CREATE ANY DIMENSION system privilege. In either case, you must 
have the READ or SELECT object privilege on any objects referenced in 
the dimension. 


Examples 
Creating a Dimension: Examples 


This statement was used to create the customers_dim dimension in the 
sample schema sh: 


CREATE DIMENSION customers_dim 
LEVEL customer IS (customers.cust_id) 
LEVEL city IS (customers.cust_city) 
LEVEL state IS (customers.cust_state_province) 
LEVEL country IS (countries.country_id) 
LEVEL subregion IS (countries.country_subregion) 
LEVEL region IS (countries.country_region) 
HIERARCHY geog_rollup ( 
customer CHILD OF 
city CHILD OF 


state CHILD OF 

country CHILD OF 

subregion CHILD OF 

region 
JOIN KEY (customers.country_id) REFERENCES country 
) 
ATTRIBUTE customer DETERMINES 
(cust_first_name, cust_last_name, cust_gender, 
cust_marital_status, cust_year_of_birth, 
cust_income_level, cust_credit_limit) 
ATTRIBUTE country DETERMINES (countries.country_name) 


Creating a Dimension with Extended Attributes: Example 


Alternatively, the extended_attribute_clause could have been used instead 
of the attribute_clause , as shown in the following example: 


CREATE DIMENSION customers_dim 

LEVEL customer IS (customers.cust_id) 
LEVEL city IS (customers.cust_city) 
LEVEL state IS (customers.cust_state_province) 
LEVEL country IS (countries.country_id) 
LEVEL subregion IS (countries.country_subregion) 
LEVEL region IS (countries.country_region) 
HIERARCHY geog_rollup ( 

customer CHILD OF 

city CHILD OF 

state CHILD OF 

country CHILD OF 

subregion CHILD OF 

region 
JOIN KEY (customers.country_id) REFERENCES country 
) 
ATTRIBUTE customer_info LEVEL customer DETERMINES 
(cust_first_name, cust_last_name, cust_gender, 
cust_marital_status, cust_year_of_birth, 


cust_income_level, cust_credit_limit) 
ATTRIBUTE country DETERMINES (countries.country_name); 


Creating a Dimension with NULL Column Values: Example 


The following example shows how to create the dimension if one of the 
level columns is null and you want to preserve the hierarchical chain. The 
example uses the cust_marital_status column for simplicity because it is not 
a NOT NULL column. If it had such a constraint, then you would have to 
disable the constraint before using the SKIP WHEN NULL clause. 


CREATE DIMENSION customers_dim 
LEVEL customer IS (customers.cust_id) 
LEVEL status IS (customers.cust_marital_status) SKIP WHEN 
NULL 
LEVEL city IS (customers.cust_city) 
LEVEL state IS (customers.cust_state_province) 
LEVEL country IS (countries.country_id) 
LEVEL subregion IS (countries.country_subregion) SKIP WHEN 
NULL 
LEVEL region IS (countries.country_region) 
HIERARCHY geog_rollup ( 
customer CHILD OF 
city CHILD OF 
state CHILD OF 
country CHILD OF 
subregion CHILD OF 
region 
JOIN KEY (customers.country_id) REFERENCES country 
) 
ATTRIBUTE customer DETERMINES 
(cust_first_name, cust_last_name, cust_gender, 
cust_marital_status, cust_year_of_birth, 
cust_income_level, cust_credit_limit) 
ATTRIBUTE country DETERMINES (countries.country_name) 


ALTER DIMENSION 


Use the ALTER DIMENSION statement to change the hierarchical 
relationships or dimension attributes of a dimension. 


The dimension must be in your schema or you must have 
the ALTER ANY DIMENSION system privilege to use this statement. 


A dimension is always altered under the rights of the owner. 
Examples 
Modifying a Dimension: Examples 


The following examples modify the customers_dim dimension in the 
sample schema sh: 


ALTER DIMENSION customers_dim 
DROP ATTRIBUTE country; 


ALTER DIMENSION customers_dim 
ADD LEVEL zone IS customers.cust_postal_code 
ADD ATTRIBUTE zone DETERMINES (cust_city); 
DROP DIMENSION 
Use the DROP DIMENSION statement to remove the named dimension. 


This statement does not invalidate materialized views that use relationships 


specified in dimensions. However, requests that have been rewritten by 


query rewrite may be invalidated, and subsequent operations on such views 


may execute more slowly. 


The dimension must be in your own schema or you must have 
the DROP ANY DIMENSION system privilege to use this statement. 


Examples 
Dropping a Dimension: Example 


This example drops the sh.customers_dim dimension: 


DROP DIMENSION customers_dim; 


CREATE ATTRIBUTE DIMENSION 


Use the CREATE ATTRIBUTE DIMENSION statement to create an 
attribute dimension. An attribute dimension specifies dimension members 
for one or more analytic view hierarchies. It specifies the data source it is 
using and the members it includes. It specifies levels for its members and 
determines attribute relationships between levels. 


To create an attribute dimension in your own schema, you must have 
the CREATE ATTRIBUTE DIMENSION system privilege. To create an 
attribute dimension in another user's schema, you must have 

the CREATE ANY ATTRIBUTE DIMENSION system privilege. 


Examples 
The following example describes the TIME_DIM table: 


desc TIME. DIM 


Name Null? Type 

MONTH_ID VARCHAR2(10) 
CATEGORY_ID NUMBER(6) 
STATE_PROVINCE_ID VARCHAR2(120) 
UNITS NUMBER(6) 

SALES NUMBER(12,2) 


YEAR_ID NOT NULL VARCHAR2(30) 
YEAR_ NAME NOT NULL VARCHAR2(40) 
YEAR_END_DATE DATE 

QUARTER_ID NOT NULL VARCHAR2(30) 
QUARTER_NAME NOT NULL VARCHAR2(40) 
QUARTER_END_DATE DATE 
QUARTER_OF_YEAR NUMBER 
MONTH_ID NOT NULL VARCHAR2(30) 
MONTH_NAME NOT NULL VARCHAR2(40) 


MONTH_END_DATE DATE 
MONTH_OF_YEAR NUMBER 
MONTH_LONG_NAME VARCHAR2(30) 


SEASON VARCHAR2(10) 


SEASON_ORDER NUMBER(38) 
MONTH_OF_QUARTER NUMBER(38) 


The following example creates a TIME type attribute dimension, using 
columns from the TIME_DIM table: 


CREATE OR REPLACE ATTRIBUTE DIMENSION time_attr_dim 
DIMENSION TYPE TIME 
USING time_dim 
ATTRIBUTES 
(year_id 
CLASSIFICATION caption VALUE 'YEAR_ID' 
CLASSIFICATION description VALUE 'YEAR ID’, 
year_name 
CLASSIFICATION caption VALUE 'YEAR_NAME' 
CLASSIFICATION description VALUE 'Year', 
year_end_date 
CLASSIFICATION caption VALUE 'YEAR_END_DATE' 
CLASSIFICATION description VALUE 'Year End Date’, 
quarter_id 
CLASSIFICATION caption VALUE 'QUARTER_ID' 
CLASSIFICATION description VALUE 'QUARTER ID', 
quarter_name 
CLASSIFICATION caption VALUE 'QUARTER_NAME' 
CLASSIFICATION description VALUE ‘Quarter’, 
quarter_end_date 
CLASSIFICATION caption VALUE 'QUARTER_END_DATE' 
CLASSIFICATION description VALUE ‘Quarter End Date’, 
quarter_of_year 
CLASSIFICATION caption VALUE 'QUARTER_OF_YEAR' 
CLASSIFICATION description VALUE ‘Quarter of Year', 
month_id 
CLASSIFICATION caption VALUE 'MONTH_ID' 
CLASSIFICATION description VALUE 'MONTH ID’, 
month_name 
CLASSIFICATION caption VALUE 'MONTH_NAME' 


CLASSIFICATION description VALUE 'Month’, 
month_long_name 
CLASSIFICATION caption VALUE 'MONTH_LONG_NAME' 
CLASSIFICATION description VALUE 'Month Long Name’, 
month_end_date 
CLASSIFICATION caption VALUE 'MONTH_END_DATE' 
CLASSIFICATION description VALUE 'Month End Date’, 
month_of_quarter 
CLASSIFICATION caption VALUE 'MONTH_OF_QUARTER' 
CLASSIFICATION description VALUE 'Month of Quarter’, 
month_of_year 
CLASSIFICATION caption VALUE 'MONTH_OF_YEAR' 
CLASSIFICATION description VALUE 'Month of Year’, 
season 
CLASSIFICATION caption VALUE 'SEASON' 
CLASSIFICATION description VALUE 'Season’, 
season_order 
CLASSIFICATION caption VALUE 'SEASON_ORDER' 
CLASSIFICATION description VALUE 'Season Order’) 
LEVEL month 
LEVEL TYPE MONTHS 
CLASSIFICATION caption VALUE 'MONTH' 
CLASSIFICATION description VALUE 'Month' 
KEY month_id 
MEMBER NAME month name 
MEMBER CAPTION month_name 
MEMBER DESCRIPTION month_long_name 
ORDER BY month_end_date 
DETERMINES (month_end_date, 
quarter_id, 
season, 
season_order, 
month_of_year, 
month_of_quarter) 
LEVEL quarter 
LEVEL TYPE QUARTERS 
CLASSIFICATION caption VALUE 'QUARTER' 


CLASSIFICATION description VALUE 'Quarter' 
KEY quarter_id 
MEMBER NAME quarter_name 
MEMBER CAPTION quarter_name 
MEMBER DESCRIPTION quarter_name 
ORDER BY quarter_end_date 
DETERMINES (quarter_end_date, 
quarter_of_year, 
year_id) 
LEVEL year 
LEVEL TYPE YEARS 
CLASSIFICATION caption VALUE "YEAR' 
CLASSIFICATION description VALUE 'Year' 
KEY year_id 
MEMBER NAME year_name 
MEMBER CAPTION year_name 
MEMBER DESCRIPTION year_name 
ORDER BY year_end_date 
DETERMINES (year_end_date) 
LEVEL season 
LEVEL TYPE QUARTERS 
CLASSIFICATION caption VALUE 'SEASON' 
CLASSIFICATION description VALUE 'Season' 
KEY season 
MEMBER NAME season 
MEMBER CAPTION season 
MEMBER DESCRIPTION season 
LEVEL month_of_quarter 
LEVEL TYPE MONTHS 
CLASSIFICATION caption VALUE 'MONTH_OF_QUARTER' 
CLASSIFICATION description VALUE 'Month of Quarter' 
KEY month_of_quarter; 


The following example describes the PRODUCT_DIM table: 


desc PRODUCT_DIM 


Name Null? Type 

DEPARTMENT_ID NOT NULL NUMBER 
DEPARTMENT_NAME NOT NULL VARCHAR2(100) 
CATEGORY_ID NOT NULL NUMBER 
CATEGORY_NAME NOT NULL VARCHAR2(100) 


The following example creates a STANDARD type attribute dimension, 
using columns from the PRODUCT_DIM table: 


CREATE OR REPLACE ATTRIBUTE DIMENSION 

product_attr_dim 

USING product_dim 

ATTRIBUTES 

(department_id, 
department_name, 
category_id, 
category_name) 

LEVEL DEPARTMENT 
KEY department_id 
ALTERNATE KEY department_name 
MEMBER NAME department_name 
MEMBER CAPTION department_name 
ORDER BY department_name 

LEVEL CATEGORY 
KEY category_id 
ALTERNATE KEY category_name 
MEMBER NAME category_name 
MEMBER CAPTION category_name 
ORDER BY category_name 
DETERMINES(department_id) 

ALL MEMBER NAME 'ALL PRODUCTS'; 


The following example describes the GEOGRAPHY_DIM table: 


desc GEOGRAPHY_DIM 


Name Null? Type 

DEPARTMENT_ID) NOT NULL NUMBER 
DEPARTMENT_NAME NOT NULL VARCHAR2(100) 
CATEGORY_ID NOT NULL NUMBER 
CATEGORY_NAME NOT NULL VARCHAR2(100) 
REGION_ID NOT NULL VARCHAR2(120) 
REGION_NAME NOT NULL VARCHAR2(100) 
COUNTRY_ID NOT NULL VARCHAR2(2) 
COUNTRY_NAME NOT NULL VARCHAR2(120) 
STATE_PROVINCE_ID NOT NULL VARCHAR2(120) 
STATE_PROVINCE_NAME NOT NULL VARCHAR2(400) 


The following example creates an STANDARD type attribute dimension, 
using columns from the GEOGRAPHY_DIM table: 


CREATE OR REPLACE ATTRIBUTE DIMENSION 
geography_attr_dim 
USING geography_dim 
ATTRIBUTES 
(region_id, 
region_name, 
country_id, 
country_name, 
state_province_id, 
state_province_name) 
LEVEL REGION 
KEY region_id 
ALTERNATE KEY region_name 
MEMBER NAME region_name 
MEMBER CAPTION region_name 
ORDER BY region_name 
LEVEL COUNTRY 
KEY country_id 


ALTERNATE KEY country_name 
MEMBER NAME country_name 
MEMBER CAPTION country_name 
ORDER BY country_name 
DETERMINES (region_id) 

LEVEL STATE_PROVINCE 
KEY state_province_id 
ALTERNATE KEY state_province_name 
MEMBER NAME state_province_name 
MEMBER CAPTION state_province_name 
ORDER BY state_province_name 
DETERMINES(country_id) 

ALL MEMBER NAME 'ALL CUSTOMERS'; 


ALTER ATTRIBUTE DIMENSION 


Use the ALTER ATTRIBUTE DIMENSION statement to rename or 
compile an attribute dimension. For other alterations, 
use CREATE OR REPLACE ATTRIBUTE DIMENSION. 


To alter an attribute dimension in your own schema, you must have 
the ALTER ATTRIBUTE DIMENSION system privilege. To alter an 
attribute dimension in another user's schema, you must have 

the ALTER ANY ATTRIBUTE DIMENSION system privilege or have 
been granted ALTER on the attribute dimension directly. 


Example 


The following statement changes the name of an attribute dimension: 


ALTER ATTRIBUTE DIMENSION product_attr_dim RENAME TO 
my_product_attr_dim; 


DROP ATTRIBUTE DIMENSION 


Use the DROP ATTRIBUTE DIMENSION statement to drop an attribute 
dimension. An ATTRIBUTE DIMENSION object is a component of 
analytic views. 


To drop an attribute dimension in your own schema, you must have 
the DROP ATTRIBUTE DIMENSION system privilege. To drop an 
analytic view in another user's schema, you must have 

the DROP ANY ATTRIBUTE DIMENSION system privilege. 


Example 


The following statement drops the specified attribute dimension object: 
DROP ATTRIBUTE DIMENSION product_attr_dim; 


INDEX 


An index is a performance-tuning method of allowing faster retrieval of 
records. An index creates an entry for each value that appears in the 
indexed columns. By default, Oracle creates B-tree indexes. 


CREATE INDEX 
Use the CREATE INDEX statement to create an index on: 
- One or more columns of a table, a partitioned table, an index- 
organized table, or a cluster 
One or more scalar typed object attributes of a table or a cluster 
- A nested table storage table for indexing a nested table column 
An index is a schema object that contains an entry for each value that 
appears in the indexed column(s) of the table or cluster and provides direct, 


fast access to rows. The maximum size of a single index entry is dependent 
on the block size of the database. 


Oracle Database supports several types of index: 
- Normal indexes. (By default, Oracle Database creates B-tree 
indexes.) 
Bitmap indexes , which store rowids associated with a key value as a 
bitmap. 
- Partitioned indexes , which consist of partitions containing an entry 
for each value that appears in the indexed column(s) of the table. 


Function-based indexes , which are based on expressions. They 
enable you to construct queries that evaluate the value returned by an 
expression, which in turn may include built-in or user-defined 
functions. 


Domain indexes , which are instances of an application-specific 
index of type indextype . 


To create an index in your own schema, one of the following conditions 
must be true: 


The table or cluster to be indexed must be in your own schema. 
- You must have the INDEX object privilege on the table to be indexed. 
You must have the CREATE ANY INDEX system privilege. 


To create an index in another schema, you must have 

the CREATE ANY INDEX system privilege. Also, the owner of the schema 
to contain the index must have either 

the UNLIMITED TABLESPACE system privilege or space quota on the 
tablespaces to contain the index or index partitions. 


To create a function-based index, in addition to the prerequisites for 
creating a conventional index, if the index is based on user-defined 
functions, then those functions must be marked DETERMINISTIC. A 
function-based index is executed with the credentials of the index owner, so 
the index owner must have the EXECUTE object privilege on the function. 


To create a domain index in your own schema, in addition to the 
prerequisites for creating a conventional index, you must also have 

the EXECUTE object privilege on the indextype. If you are creating a 
domain index in another user's schema, then the index owner also must 
have the EXECUTE object privilege on the indextype and its underlying 
implementation type. Before creating a domain index, you should first 
define the indextype. 


UNIQUE 


Specify UNIQUE to indicate that the value of the column (or columns) 
upon which the index is based must be unique. 


BITMAP 


Specify BITMAP to indicate that index is to be created with a bitmap for 
each distinct key, rather than indexing each row separately. Bitmap indexes 
store the rowids associated with a key value as a bitmap. Each bit in the 
bitmap corresponds to a possible rowid. If the bit is set, then it means that 
the row with the corresponding rowid contains the key value. The internal 
representation of bitmaps is best suited for applications with low levels of 
concurrent transactions, such as data warehousing. 


Examples 
General Index Examples 
Creating an Index: Example 


The following statement shows how the sample index ord_customer_ix on 
the customer_id column of the sample table oe.orders was created: 


CREATE INDEX ord_customer_ix 
ON orders (customer_id); 


Compressing an Index: Example 


To create the ord_customer_ix_demo index with the COMPRESS clause, 
you might issue the following statement: 


CREATE INDEX ord_customer_ix_demo 
ON orders (customer_id, sales_rep_id) 
COMPRESS 1; 


The index will compress repeated occurrences of customer_id column 
values. 


Creating an Index in NOLOGGING Mode: Example 


If the sample table orders had been created using a fast parallel load (so all 
rows were already sorted), then you could issue the following statement to 
quickly create an index. 


/* Unless you first sort the table oe.orders, this example fails 


because you cannot specify NOSORT unless the base table is 
already sorted. 
*/ 
CREATE INDEX ord_customer_ix_demo 
ON orders (order_mode) 
NOSORT 
NOLOGGING; 


Creating a Cluster Index: Example 


To create an index for the personnel cluster issue the following statement: 
CREATE INDEX idx_personnel ON CLUSTER personnel; 


No index columns are specified, because cluster indexes are automatically 
built on all the columns of the cluster key. For cluster indexes, all rows are 
indexed. 


Creating an Index on an XMLType Table: Example 


The following example creates an index on the area element of 
the xwarehouses table: 


CREATE INDEX area_index ON xwarehouses e 
(EXTRACTVALUE(VALUE(e),'/Warehouse/Area’)); 


Such an index would greatly improve the performance of queries that select 
from the table based on, for example, the square footage of a warehouse, as 
shown in this statement: 


SELECT e.getClobVal() AS warehouse 

FROM xwarehouses e 

WHERE EXISTSNODE(VALUE(e),'/Warehouse[Area>50000]') = 
1; 


Function-Based Index Examples 


The following examples show how to create and use function-based 
indexes. 


Creating a Function-Based Index: Example 


The following statement creates a function-based index on 
the employees table based on an uppercase evaluation of 
the last_name column: 


CREATE INDEX upper_ix ON employees (UPPER(last_name)); 


To increase the likelihood that Oracle Database will use the index rather 
than performing a full table scan, be sure that the value returned by the 
function is not null in subsequent queries. For example, this statement will 
use the index, unless some other condition exists that prevents the optimizer 
from doing so: 


SELECT first_name, last_name 
FROM employees WHERE UPPER(last_name) IS NOT NULL 
ORDER BY UPPER(last_name); 


Without the WHERE clause, Oracle Database may perform a full table 
scan. 


In the next statements showing index creation and subsequent query, Oracle 
Database will use index income_ix even though the columns are in reverse 
order in the query: 


CREATE INDEX income_ix 
ON employees(salary + (salary*commission_pct)); 


SELECT first_name||' '||last_name "Name" 
FROM employees 
WHERE (salary*commission_pct) + salary > 15000 
ORDER BY employee_id; 


Creating a Function-Based Index on a LOB Column: Example 


The following statement uses the text_length function to create a function- 
based index on a LOB column in the sample pm schema. The example 
selects rows from the sample table print_media where that CLOB column 
has fewer than 1000 characters. 


CREATE INDEX src_idx ON 
print_media(text_length(ad_sourcetext)); 


SELECT product_id FROM print_media 
WHERE text_length(ad_sourcetext) < 1000 
ORDER BY product_id; 


PRODUCT_ID 


Creating a Function-based Index on a Type Method: Example 


This example entails an object type rectangle containing two number 
attributes: length and width. The area() method computes the area of the 
rectangle. 


CREATE TYPE rectangle AS OBJECT 
(length NUMBER, 

width NUMBER, 

MEMBER FUNCTION area RETURN NUMBER 
DETERMINISTIC 


); 


CREATE OR REPLACE TYPE BODY rectangle AS 
MEMBER FUNCTION area RETURN NUMBER IS 
BEGIN 

RETURN (length*width); 
END; 


END; 


Now, if you create a table rect_tab of type rectangle, you can create a 
function-based index on the area() method as follows: 


CREATE TABLE rect_tab OF rectangle; 
CREATE INDEX area_idx ON rect_tab x (x.area()); 


You can use this index efficiently to evaluate a query of the form: 
SELECT * FROM rect_tab x WHERE x.area() > 100; 


Using a Function-based Index to Define Conditional Uniqueness: 
Example 


The following statement creates a unique function-based index on 
the oe.orders table that prevents a customer from taking advantage of 
promotion ID 2 ("blowout sale") more than once: 


CREATE UNIQUE INDEX promo_ix ON orders 

(CASE WHEN promotion_id =2 THEN customer_id ELSE NULL 
END, 

CASE WHEN promotion_id = 2 THEN promotion_id ELSE NULL 
END); 


INSERT INTO orders (order_id, order_date, customer_id, order_total, 
promotion_id) 

VALUES (2459, systimestamp, 106, 251, 2); 
1 row created. 


INSERT INTO orders (order_id, order_date, customer_id, order_total, 
promotion_id) 

VALUES (2460, systimestamp+1, 106, 110, 2); 
insert into orders (order_id, order_date, customer_id, order_total, 


promotion_id) 
ok 


ERROR at line 1: 
ORA-00001: unique constraint (OE.PROMO_IX) violated 


The objective is to remove from the index any rows where 

the promotion_id is not equal to 2. Oracle Database does not store in the 
index any rows where all the keys are NULL. Therefore, in this example, 
both customer_id and promotion_id are mapped to NULL unless 
promotion_id is equal to 2. The result is that the index constraint is violated 
only if promotion_id is equal to 2 for two rows with the 

same customer_id value. 


Partitioned Index Examples 
Creating a Range-Partitioned Global Index: Example 


The following statement creates a global prefixed index cost_ix on the 
sample table sh.sales with three partitions that divide the range of costs into 
three groups: 


CREATE INDEX cost_ix ON sales (amount_sold) 

GLOBAL PARTITION BY RANGE (amount_sold) 
(PARTITION p1 VALUES LESS THAN (1000), 
PARTITION p2 VALUES LESS THAN (2500), 
PARTITION p3 VALUES LESS THAN (MAXVALUB)); 


Creating a Hash-Partitioned Global Index: Example 


The following statement creates a hash-partitioned global 
index cust_last_name_ix on the sample table sh.customers with four 
partitions: 


CREATE INDEX cust_last_name_ix ON customers (cust_last_name) 
GLOBAL PARTITION BY HASH (cust_last_name) 
PARTITIONS 4; 


Creating an Index on a Hash-Partitioned Table: Example 


The following statement creates a local index on the category_id column of 
the hash_products partitioned table. The STORE IN clause immediately 
following LOCAL indicates that hash_products is hash partitioned. Oracle 
Database will distribute the hash partitions between 

the tbs1 and tbs2 tablespaces: 


CREATE INDEX prod_idx ON hash_products(category_id) LOCAL 
STORE IN (tbs_01, tbs_02); 


The creator of the index must have quota on the tablespaces specified. 
Creating an Index on a Composite-Partitioned Table: Example 


The following statement creates a local index on the composite_sales table. 
The STORAGE clause specifies default storage attributes for the index. 
However, this default is overridden for the five subpartitions of 

partitions q3_2000 and q4_2000, because separate TABLESPACE storage 
is specified. 


The creator of the index must have quota on the tablespaces specified. 


CREATE INDEX sales_ix ON composite_sales(time_id, prod_id) 

STORAGE (INITIAL 1M) 

LOCAL 

(PARTITION q1_1998, 

PARTITION q2_1998, 

PARTITION q3_1998, 

PARTITION g4_1998, 

PARTITION q1_1999, 

PARTITION q2_1999, 

PARTITION q3_1999, 

PARTITION q4_1999, 

PARTITION q1_ 2000, 

PARTITION q2_2000 
(SUBPARTITION pq2001, SUBPARTITION pq2002, 
SUBPARTITION pq2003, SUBPARTITION pq2004, 
SUBPARTITION pq2005, SUBPARTITION pq2006, 
SUBPARTITION pq2007, SUBPARTITION pq2008), 


PARTITION q3_2000 
(SUBPARTITION c1 TABLESPACE tbs_02, 
SUBPARTITION c2 TABLESPACE tbs_02, 
SUBPARTITION c3 TABLESPACE tbs_02, 
SUBPARTITION c4 TABLESPACE tbs_02, 
SUBPARTITION c5 TABLESPACE tbs_02), 
PARTITION q4_2000 
(SUBPARTITION pq4001 TABLESPACE tbs_03, 
SUBPARTITION pq4002 TABLESPACE tbs_03, 
SUBPARTITION pq4003 TABLESPACE tbs_03, 
SUBPARTITION pq4004 TABLESPACE tbs_03) 


); 


Bitmap Index Examples 
The following creates a bitmap index on the table oe.hash_products: 


CREATE BITMAP INDEX product_bm_ix 
ON hash_products(list_price) 
LOCAL(PARTITION ix_p1 TABLESPACE tbs_01, 
PARTITION ix_p2, 
PARTITION ix_p3 TABLESPACE tbs_02, 
PARTITION ix_p4 TABLESPACE tbs_03) 
TABLESPACE tbs_04; 


Because hash_products is a partitioned table, the bitmap join index must be 
locally partitioned. In this example, the user must have quota on tablespaces 


specified. 
The next series of statements shows how one might create a bitmap join 
index on a fact table using a join with a dimension table. 


CREATE TABLE hash_products 
( product_id NUMBER(6) 
, product_name VARCHAR2(50) 
, product_description VARCHAR2(2000) 
, category_id NUMBER(2) 


, weight_class NUMBER(1) 
, walranty_period INTERVAL YEAR TO MONTH 
, supplier_id NUMBER(6) 
, product_status VARCHAR2(20) 
, list_price NUMBER(8,2) 
, min_price NUMBER(8,2) 
, catalog_url VARCHAR2(50) 
, CONSTRAINT pk_product_id PRIMARY KEY 
(product_id) 
, CONSTRAINT product_status_lov_demo 
CHECK (product_status in (‘orderable' 
,'planned' 
„under development’ 
, obsolete’) 
)) 
PARTITION BY HASH (product_id) 
PARTITIONS 5 
STORE IN (example); 


CREATE TABLE sales_quota 

( product_id NUMBER(6) 

, customer_name VARCHAR2(50) 

, order_qty NUMBER(6) 
‚CONSTRAINT u_product_id UNIQUE(product_id) 
); 


CREATE BITMAP INDEX product_bm_ix 
ON hash_products(list_price) 
FROM hash_products h, sales_quota s 
WHERE h.product_id = s.product_id 
LOCAL(PARTITION ix_p1 TABLESPACE example, 
PARTITION ix_p2, 
PARTITION ix_p3 TABLESPACE example, 
PARTITION ix_p4, 
PARTITION ix_p5 TABLESPACE example) 
TABLESPACE example; 


Indexes on Nested Tables: Example 


The sample table pm.print_media contains a nested table 

column ad_textdocs_ntab, which is stored in storage 

table textdocs_nestedtab. The following example creates a unique index on 
storage table textdocs_nestedtab: 


CREATE UNIQUE INDEX nested_tab_ix 
ON textdocs_nestedtab(NESTED_TABLE_ID, document_typ); 


Including pseudocolumn NESTED_TABLE_ID ensures distinct rows in 
nested table column ad_textdocs_ntab. 


Indexing on Substitutable Columns: Examples 


You can build an index on attributes of the declared type of a substitutable 
column. In addition, you can reference the subtype attributes by using the 
appropriate TREAT function. The following example uses the table books. 
The statement creates an index on the salary attribute of all employee 
authors in the books table: 


CREATE INDEX salary_i 
ON books (TREAT(author AS employee_t).salary); 


The target type in the argument of the TREAT function must be the type 
that added the attribute being referenced. In the example, the target 
of TREAT is employee_t, which is the type that added the salary attribute. 


If this condition is not satisfied, then Oracle Database interprets 

the TREAT function as any functional expression and creates the index as a 
function-based index. For example, the following statement creates a 
function-based index on the salary attribute of part-time employees, 
assigning nulls to instances of all other types in the type hierarchy. 


CREATE INDEX salary_func_i ON persons p 
(TREAT(VALUE(p) AS part_time_emp_t).salary); 


You can also build an index on the type-discriminant column underlying a 
substitutable column by using the SYS_TYPEID function. 


The following statement creates a bitmap index on the typeid of the author 
column of the books table: 


CREATE BITMAP INDEX typeid_i ON books 
(SYS_TYPEID(author)); 


CREATE INDEXTYPE 


Use the CREATE INDEXTYPE statement to create an indextype , which 
is an object that specifies the routines that manage a domain (application- 
specific) index. Indextypes reside in the same namespace as tables, views, 
and other schema objects. This statement binds the indextype name to an 
implementation type, which in turn specifies and refers to user-defined 
index functions and procedures that implement the indextype. 


To create an indextype in your own schema, you must have 

the CREATE INDEXTYPE system privilege. To create an indextype in 
another schema, you must have the CREATE ANY INDEXTYPE system 
privilege. In either case, you must have the EXECUTE object privilege on 
the implementation type and the supported operators. 


An indextype supports one or more operators, so before creating an 
indextype, you must first design the operator or operators to be supported 
and provide functional implementation for those operators. 


Examples 
Creating an Indextype: Example 


The following statement creates an indextype 

named position_indextype and specifies the position_between operator that 
is supported by the indextype and the position_im type that implements the 
index interface. Extensible indexing scenario that uses this indextype: 


CREATE INDEXTYPE position_indextype 
FOR position_between(NUMBER, NUMBER, NUMBER) 
USING position_im; 


ALTER INDEX 
Use the ALTER INDEX statement to change or rebuild an existing index. 


The index must be in your own schema or you must have 
the ALTER ANY INDEX system privilege. 


To execute the MONITORING USAGE clause, the index must be in your 
own schema. 


To modify a domain index, you must have EXECUTE object privilege on 
the indextype of the index. 


Object privileges are granted on the parent index, not on individual index 
partitions or subpartitions. 


You must have tablespace quota to modify, rebuild, or split an index 
partition or to modify or rebuild an index subpartition. 


Examples 
Storing Index Blocks in Reverse Order: Example 


The following statement rebuilds index ord_customer_ix so that the bytes 
of the index block are stored in reverse order: 


ALTER INDEX ord_customer_ix REBUILD REVERSE; 


Rebuilding an Index in Parallel: Example 


The following statement causes the index to be rebuilt from the existing 
index by using parallel execution processes to scan the old and to build the 
new index: 


ALTER INDEX ord_customer_ix REBUILD PARALLEL; 
Modifying Real Index Attributes: Example 


The following statement alters the oe.cust_Iname_ix index so that future 
data blocks within this index use 5 initial transaction entries: 


ALTER INDEX oe.cust_lIname_ix 
INITRANS 5; 


If the oe.cust_Iname_ix index were partitioned, then this statement would 
also alter the default attributes of future partitions of the index. Partitions 
added in the future would then use 5 initial transaction entries and an 
incremental extent of 100K. 


Enabling Parallel Queries: Example 


The following statement sets the parallel attributes for index upper_ix so 
that scans on the index will be parallelized: 


ALTER INDEX upper_ix PARALLEL; 


Renaming an Index: Example 


The following statement renames an index: 
ALTER INDEX upper_ix RENAME TO upper_name_ix; 
Marking an Index Unusable: Examples 
The following statements use the cost_ix index. The first statement marks 


index partition p2 as UNUSABLE: 


ALTER INDEX cost_ix 
MODIFY PARTITION p2 UNUSABLE; 


The next statement marks the entire index cost_ix as UNUSABLE: 
ALTER INDEX cost_ix UNUSABLE; 


Rebuilding Unusable Index Partitions: Example 


The following statements rebuild partitions p2 and p3 of the cost_ix index, 
making the index once more usable: The rebuilding of partition p3 will not 
be logged: 


ALTER INDEX cost_ix 
REBUILD PARTITION p2; 
ALTER INDEX cost_ix 
REBUILD PARTITION p3 NOLOGGING; 


Changing MAXEXTENTS: Example 


The following statement changes the maximum number of extents for 
partition p3 and changes the logging attribute: 


/* This example will fail if the tablespace in which partition p3 
resides is locally managed. 

*/ 

ALTER INDEX cost_ix MODIFY PARTITION p3 
STORAGE(MAXEXTENTS 30) LOGGING; 


Renaming an Index Partition: Example 


The following statement renames an index partition of the cost_ix index: 


ALTER INDEX cost_ix 
RENAME PARITTTION p3 TO p3_Q3; 


Splitting a Partition: Example 


The following statement splits partition p2 of index cost_ix 
into p2a and p2b: 


ALTER INDEX cost_ix 
SPLIT PARTITION p2 AT (1500) 
INTO ( PARTITION p2a TABLESPACE tbs_01 LOGGING, 
PARTITION p2b TABLESPACE tbs_02); 


Dropping an Index Partition: Example 


The following statement drops index partition p1 from the cost_ix index: 


ALTER INDEX cost_ix 
DROP PARTITION p1; 


Modifying Default Attributes: Example 


The following statement alters the default attributes of local partitioned 
index prod_idx. Partitions added in the future will use 5 initial transaction 
entries: 


ALTER INDEX prod_idx 
MODIFY DEFAULT ATTRIBUTES INITRANS 5; 


ALTER INDEXTYPE 


Use the ALTER INDEXTYPE statement to add or drop an operator of the 
indextype or to modify the implementation type or change the properties of 
the indextype. 


The indextype must be in your own schema or you must have 
the ALTER ANY INDEXTYPE system privilege. 


To add a new operator, you must have the EXECUTE object privilege on 
the operator. 


To change the implementation type, you must have the EXECUTE object 
privilege on the new implementation type. 


Examples 


Altering an Indextype: Example 
ALTER INDEXTYPE position_indextype COMPILE; 


DROP INDEX 


Use the DROP INDEX statement to remove an index or domain index from 
the database. 


When you drop a global partitioned index, a range-partitioned index, or a 
hash-partitioned index, all the index partitions are also dropped. If you drop 
a composite-partitioned index, then all the index partitions and subpartitions 
are also dropped. 


In addition, when you drop a domain index: 


- Oracle Database invokes the appropriate routine. 


If any statistics are associated with the domain index, then Oracle 
Database disassociates the statistics types with the FORCE clause and 
removes the user-defined statistics collected with the statistics type. 


The index must be in your own schema or you must have 
the DROP ANY INDEX system privilege. 


Examples 
Dropping an Index: Example 


This statement drops an index named ord_customer_ix_demo: 
DROP INDEX ord_customer_ix_demo; 


DROP INDEXTYPE 


Use the DROP INDEXTYPE statement to drop an indextype as well as any 
association with a statistics type. 


The indextype must be in your own schema or you must have 
the DROP ANY INDEXTYPE system privilege. 


Examples 
Dropping an Indextype: Example 


The following statement drops the indextype position_indextype, and 
marks INVALID any domain indexes defined on this indextype: 


DROP INDEXTYPE position_indextype FORCE; 


Using Extensible Indexing 


This section provides examples of the steps entailed in a simple but realistic 
extensible indexing scenario. 


Suppose you want to rank the salaries in the HR.employees table and then 
find those that rank between 10 and 20. You could use 
the DENSE RANK function, as follows: 


SELECT last_name, salary FROM 
(SELECT last_name, DENSE_RANK() OVER 
(ORDER BY salary DESC) rank_val, salary FROM employees) 
WHERE rank_val BETWEEN 10 AND 20; 


This nested query is somewhat complex, and it requires a full scan of 
the employees table as well as a sort. An alternative would be to use 
extensible indexing to achieve the same goal. The resulting query will be 
simpler. The query will require only an index scan and a table access by 
rowid, and will therefore perform much more efficiently. 


The first step is to create the implementation type position_im, including 
method headers for index definition, maintenance, and creation. Most of the 
type body uses PL/SQL, which is shown in italics. 


The type must created with the AUTHID CURRENT_USER clause because 
of the EXECUTE IMMEDIATE statement inside the 

function ODCIINDEXCREATE(). By default that function runs with the 
definer rights. When the function is called in the subsequent creation of the 
domain index, the invoker does not have the same rights. 


CREATE OR REPLACE TYPE position_im AUTHID 
CURRENT_USER AS OBJECT 
( 

curnum NUMBER, 

howmany NUMBER, 

lower_bound NUMBER, 

upper_bound NUMBER, 


/* lower_bound and upper_bound are used for the 
index-based functional implementation */ 
STATIC FUNCTION ODCIGETINTERFACES(ifclist OUT 
SYS.ODCIOBJECTLIST) RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXCREATE 
(ia SYS.ODCIINDEXINFO, parms VARCHAR2, env 
SYS.ODCIEnv) RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXTRUNCATE (ia 
SYS.ODCIINDEXINFO, 
env SYS.ODCIEnv) RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXDROP(ia 
SYS.ODCIINDEXINFO, 
env SYS.ODCIEnv) RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXINSERT(ia 
SYS.ODCIINDEXINFO, rid ROWID, 
newval NUMBER, env SYS.ODCIEnv) 
RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXDELETE(ia 
SYS.ODCIINDEXINFO, rid ROWID, oldval NUMBER, 
env SYS.ODCIEnv) RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXUPDATE(ia 
SYS.ODCIINDEXINFO, rid ROWID, oldval NUMBER, 
newval NUMBER, env SYS.ODCIEnv) 
RETURN NUMBER, 
STATIC FUNCTION ODCIINDEXSTART(SCTX IN OUT 
position_im, ia SYS.ODCIINDEXINFO, 
op SYS.ODCIPREDINFO, qi 
SYS.ODCIQUERYINFO, 
strt NUMBER, stop NUMBER, lower_pos 
NUMBER, 
upper_pos NUMBER, env SYS.ODCIEnv) 
RETURN NUMBER, 
MEMBER FUNCTION ODCIINDEXFETCH(SELF IN OUT 
position_im, nrows NUMBER, 
rids OUT SYS.ODCIRIDLIST, env 
SYS.ODCIEnv) 
RETURN NUMBER, 


MEMBER FUNCTION ODCIINDEXCLOSE(env SYS.ODCIEnv) 
RETURN NUMBER 
); 
/ 


CREATE OR REPLACE TYPE BODY position_im 
IS 
STATIC FUNCTION ODCIGETINTERFACES(ifclist OUT 
SYS.ODCIOBJECTLIST) 
RETURN NUMBER IS 
BEGIN 
ifclist := 
SYS.ODCIOBJECTLIST(SYS.ODCIOBJECT(‘SYS',,ODCIINDEX2') 


); 
RETURN ODCICONST.SUCCESS; 

END ODCIGETINTERFACES; 
STATIC FUNCTION ODCIINDEXCREATE (ia 
SYS.ODCIINDEXINFO, parms VARCHAR2, env SYS.ODCIEnv) 
RETURN 
NUMBER 

IS 

stmt VARCHAR2(2000); 

BEGIN 
/* Construct the SQL statement */ 

stmt := 'Create Table ' || ia INDEXSCHEMA || "." || ia INDEXNAME 


| 
' STORAGE_TAB' || '(col_val, base_rowid, constraint pk 
PRIMARY KEY ' || 
'(col_val, base_rowid)) ORGANIZATION INDEX AS 
SELECT ' || 
ia. INDEXCOLS(1).COLNAME ||', ROWID FROM ' || 
ia. INDEXCOLS(1). TABLESCHEMA ||"." || 
ia. INDEXCOLS(1). TABLENAME; 
EXECUTE IMMEDIATE stmt; 
RETURN ODCICONST.SUCCESS; 
END; 


STATIC FUNCTION ODCIINDEXDROP(ia 
SYS.ODCIINDEXINFO, env SYS.ODCIEnv) RETURN NUMBER 
IS 

stmt VARCHAR2(2000); 

BEGIN 
/* Construct the SQL statement */ 

stmt := "DROP TABLE ' || ia INDEXSCHEMA ||"." || 
ia. INDEXNAME || 

" STORAGE_TAB'; 

/* Execute the statement */ 

EXECUTE IMMEDIATE stmt; 

RETURN ODCICONST.SUCCESS; 

END; 

STATIC FUNCTION ODCIINDEXTRUNCATE(ia 
SYS.ODCIINDEXINFO, env SYS.ODCIEnv) RETURN NUMBER 
IS 

stmt VARCHAR2(2000); 

BEGIN 

/* Construct the SQL statement */ 
stmt := "TRUNCATE TABLE ' || ia. INDEXSCHEMA || "."|| 
ia. INDEXNAME ||'_STORAGE_TAB'; 


EXECUTE IMMEDIATE stmt; 
RETURN ODCICONST.SUCCESS; 
END; 
STATIC FUNCTION ODCIINDEXINSERT(ia 
SYS.ODCIINDEXINFO, rid ROWID, 
newval NUMBER, env SYS.ODCIEnv) RETURN 
NUMBER IS 
stmt VARCHAR2(2000); 
BEGIN 
/* Construct the SQL statement */ 
stmt := 'INSERT INTO ' || ia INDEXSCHEMA ||". || 
ia. INDEXNAME || 
' STORAGE_TAB VALUES ("|| newval || ™ , ™ || rid |] ")'; 
/* Execute the SQL statement */ 
EXECUTE IMMEDIATE stmt; 


RETURN ODCICONST.SUCCESS; 
END; 


STATIC FUNCTION ODCIINDEXDELETE(ia 
SYS.ODCIINDEXINFO, rid ROWID, oldval NUMBER, 
env SYS.ODCIEnv) 
RETURN NUMBER IS 
stmt VARCHAR2(2000); 
BEGIN 
/* Construct the SQL statement */ 
stmt := "DELETE FROM ' || ia. INDEXSCHEMA || "." || 
ia. INDEXNAME || 
' STORAGE_TAB WHERE col_val = " || oldval || " AND 
base_rowid = " || rid || ""; 
/* Execute the statement */ 
EXECUTE IMMEDIATE stmt; 
RETURN ODCICONST.SUCCESS; 
END; 
STATIC FUNCTION ODCIINDEXUPDATE(ia 
SYS.ODCIINDEXINFO, rid ROWID, oldval NUMBER, 
newval NUMBER, env SYS.ODCIEnv) RETURN 
NUMBER IS 
stmt VARCHAR2(2000); 
BEGIN 
/* Construct the SQL statement */ 
stmt := 'UPDATE' || ia INDEXSCHEMA ||".' || ia INDEXNAME || 
' STORAGE_TAB SET col_val = " || newval ||" WHERE f2 = 
"| rid ||"; 
/* Execute the statement */ 
EXECUTE IMMEDIATE stmt; 
RETURN ODCICONST.SUCCESS; 
END; 
STATIC FUNCTION ODCIINDEXSTART(SCTX IN OUT 
position_im, ia SYS.ODCIINDEXINFO, 
op SYS.ODCIPREDINFO, qi 
SYS.ODCIQUERYINFO, 
strt NUMBER, stop NUMBER, lower_pos NUMBER, 


upper_pos NUMBER, env SYS.ODCIEnv) RETURN 

NUMBER IS 

rid VARCHAR2(5072); 

storage_tab_name VARCHAR2(65); 

lower_bound_stmt VARCHAR2(2000); 

upper_bound_stmt VARCHAR2(2000); 

range_query_stmt VARCHAR2(2000); 

lower_bound NUMBER; 

upper_bound NUMBER; 


chum INTEGER; 
nrows INTEGER; 
BEGIN 


/* Take care of some error cases. 
The only predicates in which position operator can appear are 
op) =1 OR 
op) =0 OR 
op() between 0 and 1 
e 
IF (((strt != 1) AND (strt != 0)) OR 
((stop != 1) AND (stop != 0)) OR 
((strt = 1) AND (stop = 0))) THEN 
RAISE_APPLICATION_ERROR(-20101, 
‘incorrect predicate for position_between operator’); 
END IF; 
IF (lower_pos > upper_pos) THEN 
RAISE_APPLICATION_ERROR(-20101, 'Upper Position must 
be greater than or 
equal to Lower Position’); 
END IF; 
IF (lower_pos <= 0) THEN 
RAISE _APPLICATION_ERROR(-20101, 'Both Positions must be 
greater than zero’); 
END IF; 
storage_tab_name := ia. INDEXSCHEMA || "." || ia INDEXNAME || 
' STORAGE_TAB'; 


upper_bound_stmt := 'Select MIN(col_val) FROM (Select /*+ 
INDEX_DESC¢' || 
storage_tab_name || ') */ DISTINCT ' || 
‘col_val FROM ' || storage_tab_name ||' ORDER BY ' || 
'col_val DESC) WHERE rownum <= ' || lower_pos; 
EXECUTE IMMEDIATE upper_bound_stmt INTO upper_bound; 
IF (lower_pos != upper_pos) THEN 
lower_bound_stmt := 'Select MIN(col_val) FROM (Select /*+ 
INDEX_DESC¢' || 
storage_tab_name || ') */ DISTINCT ' || 
‘col_val FROM ' || storage_tab_name || 
' WHERE col_val <' || upper_bound ||' ORDER BY ' 


'col_val DESC) WHERE rownum <= ' || 
(upper_pos - lower_pos); 
EXECUTE IMMEDIATE lower_bound_stmt INTO lower_bound; 
ELSE 
lower_bound := upper_bound; 
END IF; 
IF (lower_bound IS NULL) THEN 
lower_bound := upper_bound; 
END IF; 
range_query_stmt := 'Select base_rowid FROM ' || 
storage_tab_name || 
' WHERE col_val BETWEEN ' || lower_bound ||' AND 


‘|| 
upper_bound; 
cnum := DBMS_SQL.OPEN_CURSOR; 
DBMS_SQL.PARSE(cnum, range_query_stmt, 
DBMS_SQL.NATIVE); 
/* set context as the cursor number */ 
SCTX := position_im(cnum, 0, 0, 0); 
/* return success */ 
RETURN ODCICONST.SUCCESS; 
END; 
MEMBER FUNCTION ODCIINDEXFETCH(SELF IN OUT 
position_im, nrows NUMBER, 


rids OUT SYS.ODCIRIDLIST, env 
SYS.ODCIEnv) 

RETURN NUMBER IS 

chum INTEGER; 

rid_tab DBMS_SQL.Varchar2_ table; 

rlist SYS.ODCIRIDLIST := SYS.ODCIRIDLIST(Q); 

i INTEGER; 

d INTEGER; 

BEGIN 

cnum := SELF.curnum; 

IF self.howmany = 0 THEN 
dbms_sql.define_array(cnum, 1, rid_tab, nrows, 1); 
d := DBMS_SQL.EXECUTE(cnum); 

END IF; 

d := DBMS_SQL.FETCH_ROWS(cnum); 

IF d = nrows THEN 
rlist.extend(d); 

ELSE 
rlist.extend(d+1); 

END IF; 

DBMS_SQL.COLUMN_VALUE(cnum, 1, rid_tab); 

for i in 1..d loop 
rlist(i) := rid_tab(itSELF.howmany); 


end loop; 

SELF.howmany := SELF.howmany + d; 

rids := rlist; 

RETURN ODCICONST.SUCCESS; 
END; 


MEMBER FUNCTION ODCIINDEXCLOSE(env SYS.ODCIEnv) 
RETURN NUMBER IS 
cnum INTEGER; 
BEGIN 
cnum := SELF.curnum; 
DBMS_SQL.CLOSE_CURSOR(cnum); 
RETURN ODCICONST.SUCCESS; 
END; 
END; 


The next step is to create the functional 

implementation function_for_position_between for the operator that will be 
associated with the indextype. (The PL/SQL blocks are shown in 
parentheses.) 


This function is for use with an index-based function evaluation. Therefore, 
it takes an index context and scan context as parameters. 


CREATE OR REPLACE FUNCTION function_for_position_between 
(col NUMBER, lower_pos NUMBER, upper_pos 
NUMBER, 
indexctx IN SYS.ODClIIndexCtx, 
scanctx IN OUT position_im, 
scanflg IN NUMBER) 
RETURN NUMBER AS 
rid ROWID; 
storage_tab_name VARCHAR2(65); 
lower_bound_stmt VARCHAR2(2000); 
upper_bound_stmt VARCHAR2(2000); 
col_val_stmt VARCHAR2(2000); 
lower_bound NUMBER; 
upper_bound NUMBER; 
column_value NUMBER; 
BEGIN 
IF (indexctx.IndexInfo IS NOT NULL) THEN 
storage_tab_name := indexctx.IndexInfo.INDEXSCHEMA ||"." || 
indexctx.IndexInfo. INDEXNAME || 
' STORAGE_TAB'; 
IF (scanctx IS NULL) THEN 
/* This is the first call. Open a cursor for future calls. 
First, do some error checking 
*/ 
IF (lower_pos > upper_pos) THEN 
RAISE_APPLICATION_ERROR(-20101, 


‘Upper Position must be greater than or equal to Lower 
Position’); 
END IF; 
IF (lower_pos <= 0) THEN 
RAISE_APPLICATION_ERROR(-20101, 
‘Both Positions must be greater than zero’); 
END IF; 
/* Obtain the upper and lower value bounds for the range we're 
interested in. 
*/ 
upper_bound_stmt := 'Select MIN(col_val) FROM (Select /*+ 
INDEX_DESC¢' || 
storage_tab_name || ') */ DISTINCT ' || 
‘col_val FROM ' || storage_tab_name ||' ORDER BY ' || 
'col_val DESC) WHERE rownum <= ' || lower_pos; 
EXECUTE IMMEDIATE upper_bound_stmt INTO upper_bound; 
IF (lower_pos != upper_pos) THEN 
lower_bound_stmt := 'Select MIN(col_val) FROM (Select /*+ 
INDEX_DESC¢' || 
storage_tab_name || ') */ DISTINCT ' || 
'col_val FROM ' || storage_tab_name || 
"WHERE col_val <' || upper_bound ||' ORDER BY ' 


'col_val DESC) WHERE rownum <=' || 
(upper_pos - lower_pos); 
EXECUTE IMMEDIATE lower_bound_stmt INTO 
lower_bound; 
ELSE 
lower_bound := upper_bound; 
END IF; 
IF (ower_bound IS NULL) THEN 
lower_bound := upper_bound; 
END IF; 
/* Store the lower and upper bounds for future function invocations 
for 
the positions. 
*/ 


scanctx := position_im(0, 0, lower_bound, upper_bound); 
END IF; 
/* Fetch the column value corresponding to the rowid, and see if it 
falls 
within the determined range. 
*/ 
col_val_stmt := 'Select col_val FROM ' || storage_tab_name || 
' WHERE base_rowid = " || indexctx.Rid || ""; 
EXECUTE IMMEDIATE col_val_stmt INTO column_value; 
IF (column_value <= scanctx.upper_bound AND 
column_value >= scanctx.lower_bound AND 
scanflg = ODCICONST.RegularCall) THEN 
RETURN 1; 
ELSE 
RETURN 0; 
END IF; 
ELSE 
RAISE_APPLICATION_ERROR(-20101, 'A column that has a 
domain index of' || 
‘Position indextype must be the first argument’); 
END IF; 
END; 
/ 


Next, create the position_between operator, which uses 

the function_for_position_between function. The operator takes an 
indexed NUMBER column as the first argument, followed by 

a NUMBER lower and upper bound as the second and third arguments. 


CREATE OR REPLACE OPERATOR position_between 
BINDING (NUMBER, NUMBER, NUMBER) RETURN 
NUMBER 
WITH INDEX CONTEXT, SCAN CONTEXT position_im 
USING function_for_position_between; 


In this CREATE OPERATOR statement, 

the WITH INDEX CONTEXT, SCAN CONTEXT position_im clause is 
included so that the index context and scan context are passed in to the 
functional evaluation, which is index based. 


Now create the position_indextype indextype for the position_operator: 


CREATE INDEXTYPE position_indextype 
FOR position_between(NUMBER, NUMBER, NUMBER) 
USING position_im; 


The operator position_between uses an index-based functional 
implementation. Therefore, a domain index must be defined on the 
referenced column so that the index information can be passed into the 
functional evaluation. So the final step is to create the domain 

index salary_index using the position_indextype indextype: 


CREATE INDEX salary_index ON employees(salary) 
INDEXTYPE IS position_indextype; 


Now you can use the position_between operator function to rewrite the 
original query as follows: 


SELECT last_name, salary FROM employees 
WHERE position_between(salary, 10, 20)=1 
ORDER BY salary DESC, last_name; 


LAST NAME SALARY 
Tucker 10000 

King 10000 

Baer 10000 

Bloom 10000 

Fox 9600 

Bernstein 9500 


Sully 9500 


Greene 9500 


Hunold 9000 
Faviet 9000 
McEwen 9000 
Hall 9000 
Hutton 8800 
Taylor 8600 
Livingston 8400 
Gietz 8300 
Chen 8200 
Fripp 8200 
Weiss 8000 
Olsen 8000 
Smith 8000 
Kaufling 7900 
SYNONYM 


Synonyms are a very powerful feature of Oracle. They are auxiliary names 
that relate to other database objects: tables, procedures, views, etc. They 
work like Unix hard links; a pointer to point to an object that exists 
somewhere else. 


Synonyms can be created as PRIVATE (by default) or PUBLIC. 


e public synonyms are available to all users in the database. 
e private synonyms exist only in specific user schema (they are 
available only to a user and to grantees for the underlying object) 


CREATE SYNONYM 


Use the CREATE SYNONYM statement to create a synonym , which is an 
alternative name for a table, view, sequence, operator, procedure, stored 
function, package, materialized view, Java class schema object, user- 
defined object type, or another synonym. A synonym places a dependency 
on its target object and becomes invalid if the target object is changed or 
dropped. 


Synonyms provide both data independence and location transparency. 
Synonyms permit applications to function without modification regardless 
of which user owns the table or view and regardless of which database 
holds the table or view. However, synonyms are not a substitute for 
privileges on database objects. Appropriate privileges must be granted to a 
user before the user can use the synonym. 


You can refer to synonyms in the following DML 
statements: SELECT, INSERT, UPDATE, DELETE, FLASHBACK TABL 
E, EXPLAIN PLAN, LOCK TABLE, MERGE, and CALL. 


You can refer to synonyms in the following DDL 
statements: AUDIT, NOAUDIT, GRANT, REVOKE, and COMMENT. 


To create a private synonym in your own schema, you must have 
the CREATE SYNONYM system privilege. 


To create a private synonym in another user's schema, you must have 
the CREATE ANY SYNONYM system privilege. 


To create a PUBLIC synonym, you must have 
the CREATE PUBLIC SYNONYM system privilege. 


Examples 
CREATE SYNONYM: Examples 


To define the synonym offices for the table locations in the schema hr, issue 
the following statement: 


CREATE SYNONYM offices 
FOR hr.locations; 


To create a PUBLIC synonym for the employees table in the schema hr on 
the remote database, you could issue the following statement: 


CREATE PUBLIC SYNONYM emp_table 
FOR hr.employees@remote.us.example.com; 


A synonym may have the same name as the underlying object, provided the 
underlying object is contained in another schema. 


Oracle Database Resolution of Synonyms: Example 


Oracle Database attempts to resolve references to objects at the schema 
level before resolving them at the PUBLIC synonym level. For example, 
the schemas oe and sh both contain tables named customers. In the next 
example, user SYSTEM creates a PUBLIC synonym 

named customers for oe.customers: 


CREATE PUBLIC SYNONYM customers FOR oe.customers; 


If the user sh then issues the following statement, then the database returns 
the count of rows from sh.customers: 


SELECT COUNT(*) FROM customers; 


To retrieve the count of rows from oe.customers, the user sh must 
preface customers with the schema name. (The user sh must have select 
permission on oe.customers as well.) 


SELECT COUNT(*) FROM oe.customers; 


If the user hr's schema does not contain an object named customers, and 
if hr has select permission on oe.customers, then hr can access 
the customers table in oe's schema by using the public synonym customers: 


SELECT COUNT(*) FROM customers; 


ALTER SYNONYM 
Use the ALTER SYNONYM statement to modify an existing synonym. 


To modify a private synonym in another user's schema, you must have 
the CREATE ANY SYNONYM and DROP ANY SYNONYM system 
privileges. 


To modify a PUBLIC synonym, you must have 
the CREATE PUBLIC SYNONYM and DROP PUBLIC SYNONYM syste 
m privileges. 


Examples 


The following examples modify synonyms that were created in 
the CREATE SYNONYM. 


The following statement compiles synonym offices: 
ALTER SYNONYM offices COMPILE; 

The following statement compiles public synonym emp_table: 
ALTER PUBLIC SYNONYM emp_table COMPILE; 


The following statement causes synonym offices to remain a noneditioned 
object if editioning is later enabled for schema object type SYNONYM in 
the schema that contains the synonym offices: 


ALTER SYNONYM offices NONEDITIONABLE; 


DROP SYNONYM 


Use the DROP SYNONYM statement to remove a synonym from the 
database or to change the definition of a synonym by dropping and re- 
creating it. 


To drop a private synonym, either the synonym must be in your own 
schema or you must have the DROP ANY SYNONYM system privilege. 


To drop a PUBLIC synonym, you must have 
the DROP PUBLIC SYNONYM system privilege. 


Examples 
Dropping a Synonym: Example 


To drop the public synonym named customers, issue the following 
statement: 


DROP PUBLIC SYNONYM customers; 


SEQUENCE 


A sequence is an object in Oracle that is used to generate a number 
sequence. This can be useful when you need to create a unique number to 
act as a primary key. 


CREATE SEQUENCE 


Use the CREATE SEQUENCE statement to create a sequence , which is a 
database object from which multiple users may generate unique integers. 
You can use sequences to automatically generate primary key values. 


When a sequence number is generated, the sequence is incremented, 
independent of the transaction committing or rolling back. If two users 
concurrently increment the same sequence, then the sequence numbers each 
user acquires may have gaps, because sequence numbers are being 
generated by the other user. One user can never acquire the sequence 
number generated by another user. After a sequence value is generated by 
one user, that user can continue to access that value regardless of whether 
the sequence is incremented by another user. 


Sequence numbers are generated independently of tables, so the same 
sequence can be used for one or for multiple tables. It is possible that 
individual sequence numbers will appear to be skipped, because they were 
generated and used in a transaction that ultimately rolled back. 

Additionally, a single user may not realize that other users are drawing from 
the same sequence. 


After a sequence is created, you can access its values in SQL statements 
with the CURRVAL pseudocolumn, which returns the current value of the 


sequence, or the NEXTVAL pseudocolumn, which increments the sequence 
and returns the new value. 


To create a sequence in your own schema, you must have 
the CREATE SEQUENCE system privilege. 


To create a sequence in another user's schema, you must have 
the CREATE ANY SEQUENCE system privilege. 


Examples 
Creating a Sequence: Example 


The following statement creates the sequence customers_seq in the sample 
schema oe. This sequence could be used to provide customer ID numbers 
when rows are added to the customers table. 


CREATE SEQUENCE customers_seq 
START WITH 1000 

INCREMENT BY 1 

NOCACHE 

NOCYCLE; 


The first reference to customers_seq.nextval returns 1000. The second 
returns 1001. Each subsequent reference will return a value 1 greater than 
the previous reference. 


ALTER SEQUENCE 


Use the ALTER SEQUENCE statement to change the increment, minimum 
and maximum values, cached numbers, and behavior of an existing 
sequence. This statement affects only future sequence numbers. 


The sequence must be in your own schema, or you must have 
the ALTER object privilege on the sequence, or you must have 
the ALTER ANY SEQUENCE system privilege. 


Examples 
Modifying a Sequence: Examples 


This statement sets a new maximum value for the customers_seq sequence: 


ALTER SEQUENCE customers_seq 
MAXVALUE 1500; 


This statement turns on CYCLE and CACHE for 
the customers_seq sequence: 


ALTER SEQUENCE customers_seq 
CYCLE 
CACHE 5; 


DROP SEQUENCE 


Use the DROP SEQUENCE statement to remove a sequence from the 
database. 


You can also use this statement to restart a sequence by dropping and then 
re-creating it. For example, if you have a sequence with a current value of 
150 and you would like to restart the sequence with a value of 27, then you 
can drop the sequence and then re-create it with the same name and 

a START WITH value of 27. 


The sequence must be in your own schema or you must have 
the DROP ANY SEQUENCE system privilege. 


Examples 
Dropping a Sequence: Example 


The following statement drops the sequence customers_seq owned by the 
user oe. To issue this statement, you must either be connected as user oe or 
have the DROP ANY SEQUENCE system privilege: 


DROP SEQUENCE oe.customers_seq; 


FUNCTION 


A function is a subprogram that is used to return a single value. You must 
declare and define a function before invoking it. It can be declared and 


defined at a same time or can be declared first and defined later in the same 
block. 


CREATE FUNCTION 


Functions are defined using PL/SQL. Use 
the CREATE FUNCTION statement to create a standalone stored function 
or a call specification. 


A stored function (also called a user function or user-defined 
function ) is a set of PL/SQL statements you can call by name. Stored 
functions are very similar to procedures, except that a function returns 
a value to the environment in which it is called. User functions can be 
used as part of a SQL expression. 


A call specification declares a Java method or a third-generation 
language (3GL) routine so that it can be called from PL/SQL. You can 
also use the CALL SQL statement to call such a method or routine. 
The call specification tells Oracle Database which Java method, or 
which named function in which shared library, to invoke when a call 
is made. It also tells the database what type conversions to make for 
the arguments and return value. 


To create or replace a function in your own schema, you must have 
the CREATE PROCEDURE system privilege. To create or replace a 
function in another user's schema, you must have 

the CREATE ANY PROCEDURE system privilege. 


Examples 
Creating a Function 


This statement creates the function get_bal on the sample table oe.orders. 


CREATE FUNCTION get_bal(acc_no IN NUMBER) 
RETURN NUMBER 
IS acc_bal NUMBER(11,2); 
BEGIN 
SELECT order_total 
INTO acc_bal 
FROM orders 


WHERE customer_id = acc_no; 
RETURN(acc_bal); 
END; 
/ 


The get_bal function returns the balance of a specified account. 


When you invoke the function, you must specify the argument acc_no, the 
number of the account whose balance is sought. The data type 
of acc_no is NUMBER. 


The function returns the account balance. The RETURN clause of 
the CREATE FUNCTION statement specifies the data type of the return 
value to be NUMBER. 


The function uses a SELECT statement to select the balance column from 
the row identified by the argument acc_no in the orders table. The function 
uses a RETURN statement to return this value to the environment in which 
the function is called. 


The function created in the preceding example can be used in a SQL 
statement. For example: 


SELECT get_bal(165) FROM DUAL; 


GET_BAL(165) 


Creating Aggregate Functions 


The next statement creates an aggregate function called SecondMax to 
aggregate over number values. It assumes that the 

ADT SecondMaxImpl subprograms contains the implementations of 
the ODCIAggregate subprograms: 


CREATE FUNCTION SecondMax (input NUMBER) RETURN 
NUMBER 
PARALLEL_ENABLE AGGREGATE USING SecondMaxImpl; 


Use such an aggregate function in a query like this statement, which queries 
the sample table hr.employees: 


SELECT SecondMax(salary) "SecondMax", department_id 
FROM employees 
GROUP BY department_id 
HAVING SecondMax(salary) > 9000 
ORDER BY "SecondMax", department_id; 


SecondMax DEPARTMENT_ID 


9450 100 
13670.74 50 
14175 80 
18742.5 90 


Package Procedure in a Function 


This statement creates a function that uses 
a DBMS_LOB.GETLENGTH procedure to return the length of 
a CLOB column. 


CREATE OR REPLACE FUNCTION text_length(a CLOB) 
RETURN NUMBER DETERMINISTIC IS 

BEGIN 
RETURN DBMS_LOB.GETLENGTH(a); 

END; 


ALTER FUNCTION 


Functions are defined using PL/SQL. Therefore, this section provides some 
general information. 


Use the ALTER FUNCTION statement to recompile an invalid standalone 
stored function. Explicit recompilation eliminates the need for implicit run- 


time recompilation and prevents associated run-time compilation errors and 
performance overhead. 


This statement does not change the declaration or definition of an existing 
function. To redeclare or redefine a function, use 
the CREATE FUNCTION statement with the OR REPLACE clause. 


The function must be in your own schema or you must 
have ALTER ANY PROCEDURE system privilege. 


Example 
Recompiling a Function 


To explicitly recompile the function get_bal owned by the sample user oe, 
issue this statement: 


ALTER FUNCTION oe.get_bal COMPILE; 


If the database encounters no compilation errors while recompiling get_bal, 
then get_bal becomes valid. The database can subsequently run it without 
recompiling it at run time. If recompiling get_bal results in compilation 
errors, then the database returns an error, and get_bal remains invalid. 


The database also invalidates all objects that depend upon get_bal. If you 
subsequently reference one of these objects without explicitly recompiling 
it first, then the database recompiles it implicitly at run time. 


DROP FUNCTION 


Functions are defined using PL/SQL. Use the DROP FUNCTION statement 
to remove a standalone stored function from the database. 


The function must be in your own schema or you must have 
the DROP ANY PROCEDURE system privilege. 


Examples 
Dropping a Function: Example 


The following statement drops the function SecondMax in the sample 
schema oe and invalidates all objects that depend upon SecondMax: 


DROP FUNCTION oe.SecondMax; 


PROCEDURE 


A procedure is a group of PL/SQL statements that you can call by name. A 
call specification (sometimes called call spec) declares a Java method or a 
third-generation language (3GL) routine so that it can be called from SQL 
and PL/SQL. The call spec tells Oracle Database which Java method to 
invoke when a call is made. 


CREATE PROCEDURE 


Procedures are defined using PL/SQL. Use 
the CREATE PROCEDURE statement to create a standalone stored 
procedure or a call specification. 


A procedure is a group of PL/SQL statements that you can call by name. 
A call specification (sometimes called call spec) declares a Java method 
or a third-generation language (3GL) routine so that it can be called from 
SQL and PL/SQL. The call spec tells Oracle Database which Java method 
to invoke when a call is made. It also tells the database what type 
conversions to make for the arguments and return value. 


Stored procedures offer advantages in the areas of development, integrity, 
security, performance, and memory allocation. 


To create or replace a procedure in your own schema, you must have 
the CREATE PROCEDURE system privilege. To create or replace a 
procedure in another user's schema, you must have 

the CREATE ANY PROCEDURE system privilege. 


To invoke a call spec, you may need additional privileges, for example, 
the EXECUTE object privilege on the C library for a C call spec. 


To embed a CREATE PROCEDURE statement inside an Oracle 
precompiler program, you must terminate the statement with the 

keyword END-EXEC followed by the embedded SQL statement terminator 
for the specific language. 


Examples 


Creating a Procedure 


This statement creates the procedure remove_emp in the schema hr. 


CREATE PROCEDURE remove_emp (employee_id NUMBER) AS 
tot_emps NUMBER; 
BEGIN 
DELETE FROM employees 
WHERE employees.employee_id = remove_emp.employee_id; 
tot_emps := tot_emps - 1; 
END; 
/ 


The remove_emp procedure removes a specified employee. When you 
invoke the procedure, you must specify the employee_id of the employee to 
be removed. 


The procedure uses a DELETE statement to remove from the employees 
table the row of employee_id. 


Creating an External Procedure 


In this example, external procedure c_find_root expects a pointer as a 
parameter. Procedure find_root passes the parameter by reference using 
the BY REFERENCE phrase. 


CREATE PROCEDURE find_root 
(x IN REAL ) 
IS LANGUAGE C 
NAME c _find_root 
LIBRARY c_utils 
PARAMETERS ( x BY REFERENCE ); 


ALTER PROCEDURE 


Packages are defined using PL/SQL. Use 
the ALTER PROCEDURE statement to explicitly recompile a standalone 
stored procedure. Explicit recompilation eliminates the need for implicit 


run-time recompilation and prevents associated run-time compilation errors 
and performance overhead. 


To recompile a procedure that is part of a package, recompile the entire 
package using the ALTER PACKAGE statement. 


The procedure must be in your own schema or you must 
have ALTER ANY PROCEDURE system privilege. 


Example 
Recompiling a Procedure 


To explicitly recompile the procedure remove_emp owned by the user hr, 
issue this statement: 


ALTER PROCEDURE hr.remove_emp COMPILE; 


If the database encounters no compilation errors while 

recompiling remove_emp, then remove_emp becomes valid. The database 
can subsequently run it without recompiling it at run time. If 

recompiling remove_emp results in compilation errors, then the database 
returns an error and remove_emp remains invalid. 


the database also invalidates all dependent objects. These objects include 
any procedures, functions, and package bodies that invoke remove_emp. If 
you subsequently reference one of these objects without first explicitly 
recompiling it, then the database recompiles it implicitly at run time. 


DROP PROCEDURE 


Procedures are defined using PL/SQL. Use 

the DROP PROCEDURE statement to remove a standalone stored 
procedure from the database. Do not use this statement to remove a 
procedure that is part of a package. Instead, either drop the entire package 
using the DROP PACKAGE statement, or redefine the package without the 
procedure using the CREATE PACKAGE statement with 

the OR REPLACE clause. 


The procedure must be in your own schema or you must have 
the DROP ANY PROCEDURE system privilege. 


Examples 
Dropping a Procedure: Example 


The following statement drops the procedure remove_emp owned by the 
user hr and invalidates all objects that depend upon remove_emp: 


DROP PROCEDURE hr.remove_emp; 


PACKAGE 


In PL/SQL, a package is a schema object that contains definitions for a 
group of related functionalities. A package includes variables, constants, 
cursors, exceptions, procedures, functions, and subprograms. It is compiled 
and stored in the Oracle Database. 


Typically, a package has a specification and a body. A package specification 
is mandatory while the package body can be required or optional, 
depending on the package specification. 


CREATE PACKAGE 


Packages are defined using PL/SQL. Use 

the CREATE PACKAGE statement to create the specification for a stored 
package , which is an encapsulated collection of related procedures, 
functions, and other program objects stored together in the database. The 
package specification declares these objects. The package body , 
specified subsequently, defines these objects. 


To create or replace a package in your own schema, you must have 
the CREATE PROCEDURE system privilege. To create or replace a 
package in another user's schema, you must have 

the CREATE ANY PROCEDURE system privilege. 


To embed a CREATE PACKAGE statement inside an Oracle Database 
precompiler program, you must terminate the statement with the 

keyword END-EXEC followed by the embedded SQL statement terminator 
for the specific language. 


Example 


Creating the Specification for the emp_mgmt Package 


This statement creates the specification of the emp_mgmt package. 


CREATE OR REPLACE PACKAGE emp_mgmt AS 
FUNCTION hire (last_name VARCHAR2, job_id VARCHAR2, 
manager_id NUMBER, salary NUMBER, 
commission_pct NUMBER, department_id NUMBER) 
RETURN NUMBER; 
FUNCTION create_dept(department_id NUMBER, location_id 
NUMBER) 
RETURN NUMBER; 
PROCEDURE remove_emp(employee_id NUMBER); 
PROCEDURE remove_dept(department_id NUMBER); 
PROCEDURE increase_sal(employee_id NUMBER, salary_incr 
NUMBER); 
PROCEDURE increase_comm(employee_id NUMBER, comm_incr 
NUMBER); 
no_comm EXCEPTION; 
no_sal EXCEPTION; 
END emp_mgmt; 


The specification for the emp_mgmt package declares these public program 
objects: 
The functions hire and create_dept 


The procedures remove_emp, remove_dept, increase_sal, 
and increase_comm 


The exceptions no_comm and no_sal 


All of these objects are available to users who have access to the package. 
After creating the package, you can develop applications that invoke any of 
these public procedures or functions or raise any of the public exceptions of 
the package. 


Before you can invoke this package's procedures and functions, you must 
define these procedures and functions in the package body. 


CREATE PACKAGE BODY 


Package bodies are defined using PL/SQL. Use 

the CREATE PACKAGE BODY statement to create the body of a stored 
package , which is an encapsulated collection of related procedures, stored 
functions, and other program objects stored together in the database. The 
package body defines these objects. The package specification , defined 
in an earlier CREATE PACKAGE statement, declares these objects. 


Packages are an alternative to creating procedures and functions as 
standalone schema objects. 


To create or replace a package in your own schema, you must have 
the CREATE PROCEDURE system privilege. To create or replace a 
package in another user's schema, you must have 

the CREATE ANY PROCEDURE system privilege. In both cases, the 
package body must be created in the same schema as the package. 


To embed a CREATE PACKAGE BODY statement inside an Oracle 
Database precompiler program, you must terminate the statement with the 
keyword END-EXEC followed by the embedded SQL statement terminator 
for the specific language. 


Examples 


Creating the emp_mgmt Package Body 


CREATE OR REPLACE PACKAGE BODY emp_mgmt AS 
tot_emps NUMBER; 
tot_depts NUMBER; 
FUNCTION hire 
(last_name VARCHAR2, job_id VARCHAR2, 
manager_id NUMBER, salary NUMBER, 
commission_pct NUMBER, department_id NUMBER) 
RETURN NUMBER IS new_empno NUMBER; 
BEGIN 
SELECT employees_seq.NEXTVAL 
INTO new_empno 
FROM DUAL; 
INSERT INTO employees 
VALUES (new_empno, 'First', 
'Last','first.example@example.com’, 


'(415)555-0100', 
TO_DATE(‘18-JUN-2002',,DD-MON-YYYY’), 
'TT_PROG',90000000,00, 100,110); 
tot_emps := tot_emps + 1; 
RETURN(new_empno); 
END; 
FUNCTION create_dept(department_id NUMBER, location_id 
NUMBER) 
RETURN NUMBER IS 
new_deptno NUMBER; 
BEGIN 
SELECT departments_seq.NEXTVAL 
INTO new_deptno 
FROM dual; 
INSERT INTO departments 
VALUES (new_deptno, 'department name’, 100, 1700); 
tot_depts := tot_depts + 1; 
RETURN(new_deptno); 
END; 
PROCEDURE remove_emp (employee_id NUMBER) IS 
BEGIN 
DELETE FROM employees 
WHERE employees.employee_id = remove_emp.employee_id; 
tot_emps := tot_emps - 1; 
END; 
PROCEDURE remove_dept(department_id NUMBER) IS 
BEGIN 
DELETE FROM departments 
WHERE departments.department_id = 
remove_dept.department_id; 
tot_depts := tot_depts - 1; 
SELECT COUNT(*) INTO tot_emps FROM employees; 
END; 
PROCEDURE increase_sal(employee_id NUMBER, salary_incr 
NUMBER) IS 
curr_sal NUMBER; 
BEGIN 


SELECT salary INTO curr_sal FROM employees 
WHERE employees.employee_id = increase_sal.employee_id; 
IF curr_sal IS NULL 
THEN RAISE no_sal; 
ELSE 
UPDATE employees 
SET salary = salary + salary_incr 
WHERE employee_id = employee_id; 
END IF; 
END; 
PROCEDURE increase_comm(employee_id NUMBER, comm_incr 
NUMBER) IS 
curr_comm NUMBER; 
BEGIN 
SELECT commission_pct 
INTO curr_comm 
FROM employees 
WHERE employees.employee_id = increase_comm.employee_id; 
IF curr_comm IS NULL 
THEN RAISE no_comm; 
ELSE 
UPDATE employees 
SET commission_pct = commission_pct + comm_ incr; 
END IF; 
END; 
END emp_mgmt; 


The package body defines the public program objects declared in the 
package specification: 

The functions hire and create_dept 

The procedures remove_emp, remove_dept, increase_sal, 

and increase_comm 


These objects are declared in the package specification, so they can be 
called by application programs, procedures, and functions outside the 
package. For example, if you have access to the package, you can create a 


procedure increase_all_ comms separate from the emp_mgmt package that 
invokes the increase_comm procedure. 


These objects are defined in the package body, so you can change their 
definitions without causing the database to invalidate dependent schema 
objects. For example, if you subsequently change the definition of hire, then 
the database need not recompile increase_all_comms before running it. 


The package body in this example also declares private program objects, 
the variables tot_emps and tot_depts. These objects are declared in the 
package body rather than the package specification, so they are accessible 
to other objects in the package, but they are not accessible outside the 
package. For example, you cannot develop an application that explicitly 
changes the value of the variable tot_depts. However, the 

function create_dept is part of the package, so create_dept can change the 
value of tot_depts. 


ALTER PACKAGE 
Packages are defined using PL/SQL. 


Use the ALTER PACKAGE statement to explicitly recompile a package 
specification, body, or both. Explicit recompilation eliminates the need for 
implicit run-time recompilation and prevents associated run-time 
compilation errors and performance overhead. 


Because all objects in a package are stored as a unit, 

the ALTER PACKAGE statement recompiles all package objects together. 
You cannot use the ALTER PROCEDURE statement 

or ALTER FUNCTION statement to recompile individually a procedure or 
function that is part of a package. 


For you to modify a package, the package must be in your own schema or 
you must have ALTER ANY PROCEDURE system privilege. 


Examples 
Recompiling a Package 


This statement explicitly recompiles the specification and body of 
the hr.emp_mgmt package. 


ALTER PACKAGE emp_mgmt COMPILE PACKAGE; 


If the database encounters no compilation errors while recompiling 

the emp_mgmt specification and body, then emp_mgmt becomes valid. The 
user hr can subsequently invoke or reference all package objects declared in 
the specification of emp_mgmt without runtime recompilation. If 
recompiling emp_mgmt results in compilation errors, then the database 
returns an error and emp_mgmt remains invalid. 


The database also invalidates all objects that depend upon emp_mgmt. If 
you subsequently reference one of these objects without explicitly 
recompiling it first, then the database recompiles it implicitly at run time. 


To recompile the body of the emp_mgmt package in the schema hr, issue 
this statement: 


ALTER PACKAGE hr.emp_mgmt COMPILE BODY; 


If the database encounters no compilation errors while recompiling the 
package body, then the body becomes valid. The user hr can subsequently 
invoke or reference all package objects declared in the specification 

of emp_mgmt without runtime recompilation. If recompiling the body 
results in compilation errors, then the database returns an error message and 
the body remains invalid. 


Because this statement recompiles the body and not the specification 
of emp_mgmt, the database does not invalidate dependent objects. 


DROP PACKAGE 


Packages are defined using PL/SQL. Use the DROP PACKAGE statement 
to remove a stored package from the database. This statement drops the 
body and specification of a package. 


The package must be in your own schema or you must have 
the DROP ANY PROCEDURE system privilege. 


Examples 


Dropping a Package: Example 


The following statement drops the specification and body of 
the emp_mgmt package, invalidating all objects that depend on the 
specification. 


DROP PACKAGE emp_mgmt; 


TYPE 


Oracle object types are user-defined types that make it possible to model 
real-world entities, such as customers and purchase orders, as objects in the 
database. New object types can be created from any built-in database types 
and any previously created object types, object references, and collection 


types. 


An object type can represent any real-world entity. For example, an object 
type can represent a student, bank account, computer screen, rational 
number, or data structure such as a queue, stack, or list. Currently, you 
cannot define object types in a PL/SQL block, subprogram, or package. 


CREATE TYPE 


Object types are defined using PL/SQL. Use the CREATE TYPE statement 
to create the specification of an object type ,a SQLJ object type, a 
named varying array ( varray ), a nested table type , or an incomplete 
object type . You create object types with the CREATE TYPE and 

the CREATE TYPE BODY statements. The CREATE TYPE statement 
specifies the name of the object type, its attributes, methods, and other 
properties. The CREATE TYPE BODY statement contains the code for the 
methods that implement the type. 


An incomplete type is a type created by a forward type definition. It is 
called "incomplete" because it has a name but no attributes or methods. It 
can be referenced by other types, and so can be used to define types that 
refer to each other. However, you must fully specify the type before you can 
use it to create a table or an object column or a column of a nested table 


type. 


To create a type in your own schema, you must have 
the CREATE TYPE system privilege. To create a type in another user's 


schema, you must have the CREATE ANY TYPE system privilege. You can 
acquire these privileges explicitly or be granted them through a role. 


To create a subtype, you must have the UNDER ANY TYPE system 
privilege or the UNDER object privilege on the supertype. 


The owner of the type must be explicitly granted the EXECUTE object 
privilege in order to access all other types referenced within the definition 
of the type, or the type owner must be granted 

the EXECUTE ANY TYPE system privilege. The owner cannot obtain 
these privileges through roles. 


If the type owner intends to grant other users access to the type, then the 
owner must be granted the EXECUTE object privilege on the referenced 
types with the GRANT OPTION or the EXECUTE ANY TYPE system 
privilege with the ADMIN OPTION. Otherwise, the type owner has 
insufficient privileges to grant access on the type to other users. 


User-Defined Datatypes Declared as Non-Persistable Datatypes 
You can specify a user-defined datatype as non-persistable when creating 


the datatype. Instances of non-persistable types cannot persist on disk. 
Perisistable data types include the following: 


- ANSI-supported data types, for 
example NUMERIC, DECIMAL, REAL. 


Oracle built-in data types, for 
example NUMBER, VARCHAR2, TIMESTAMP. 


- Oracle-supplied data types, for example ANYDATA, XML 
Type, ORDImage. 
Rules For SQL User-Defined Data Types 
- A persistable type cannot have attributes or elements of non- 
persistable types. 


A non-persistable type can have attributes or elements of both 
persistable and non-persistable types. 


- A sub-type must inherit the persistence property from its super type. 


A REF type is persistable and can hold references only to objects of 
persistable types. 


You cannot persist instances of non-persistable types on disk. If you 
create a table with a type that has been declared as non-persistable, 
the CREATE TABLE statement will fail. The following operations 
will likewise fail: 

o Create or alter a relational table with columns of non-persistable 


types. 
o Create an object table with columns of non-persistable types. 


o Store instances of non-persistable types in 
an ANYDATA instance which is persisted on disk. 


CREATE TYPE BODY 


Type bodies are defined using PL/SQL. Use the CREATE TYPE BODY to 
define or implement the member methods defined in the object type 
specification. You create object types with the CREATE TYPE and 

the CREATE TYPE BODY statements. The CREATE TYPE statement 
specifies the name of the object type, its attributes, methods, and other 
properties. The CREATE TYPE BODY statement contains the code for the 
methods that implement the type. 


For each method specified in an object type specification for which you did 
not specify the call_spec, you must specify a corresponding method body 
in the object type body. 


Every member declaration in the CREATE TYPE specification for object 
types must have a corresponding construct in 
the CREATE TYPE or CREATE TYPE BODY statement. 


To create or replace a type body in your own schema, you must have 

the CREATE TYPE or the CREATE ANY TYPE system privilege. To 
create an object type in another user's schema, you must have 

the CREATE ANY TYPE system privilege. To replace an object type in 
another user's schema, you must have the DROP ANY TYPE system 
privilege. 

ALTER TYPE 

Object types are defined using PL/SQL. Use the ALTER TYPE statement to 
add or drop member attributes or methods. You can change the existing 


properties (FINAL or INSTANTIABLE) of an object type, and you can 
modify the scalar attributes of the type. 


You can also use this statement to recompile the specification or body of the 
type or to change the specification of an object type by adding new object 
member subprogram specifications. 


The object type must be in your own schema and you must 
have CREATE TYPE or CREATE ANY TYPE system privilege, or you 
must have ALTER ANY TYPE system privileges. 


DROP TYPE 


Object types are defined using PL/SQL. Use the DROP TYPE statement to 
drop the specification and body of an object type, a varray, or a nested table 


type. 


The object type, varray, or nested table type must be in your own schema or 
you must have the DROP ANY TYPE system privilege. 


Examples 
Dropping an Object Type: Example 


The following statement removes object type person_t. Any columns that 
are dependent on person_t are marked UNUSED and become inaccessible. 


DROP TYPE person_t FORCE; 


DROP TYPE BODY 


Object types are defined using PL/SQL. Use 

the DROP TYPE BODY statement to drop the body of an object type, 
varray, or nested table type. When you drop a type body, the object type 
specification still exists, and you can re-create the type body. Prior to re- 
creating the body, you can still use the object type, although you cannot call 
the member functions. 


The object type body must be in your own schema or you must have 
the DROP ANY TYPE system privilege. 


Examples 
Dropping an Object Type Body: Example 
The following statement removes object type body data_typ1. 


DROP TYPE BODY data_typ1; 


CONTEXT 


A context is a set of application-defined attributes associated with a 
namespace that is linked to a managing package. A context is created using 
the CREATE CONTEXT statement in which the namespace equates to the 
context name. 


Context attributes can be read using the sys_context function available from 
SQL and PL/SQL. The following example uses this function to retrieve the 
current session identifier from the default userenv context. 


CREATE CONTEXT 
Use the CREATE CONTEXT statement to: 


Create a namespace for a context (a set of application-defined 
attributes that validates and secures an application) 


- Associate the namespace with the externally created package that sets 
the context 


You can use the DBMS_SESSION.SET_CONTEXT procedure in your 
designated package to set or reset the attributes of the context. 


To create a context namespace, you must 
have CREATE ANY CONTEXT system privilege. 


Examples 
Creating an Application Context: Example 


This example uses a PL/SQL package emp_mgmt, which validates and 
secures a human resources application. The following statement creates the 
context namespace hr_context and associates it with the 

package emp_mgmt: 


CREATE CONTEXT hr_context USING emp_mgmt; 


You can control data access based on this context using 

the SYS_CONTEXT function. For example, the emp_mgmt package has 
defined an attribute department_id as a particular department identifier. You 
can secure the base table employees by creating a view that restricts access 
based on the value of department_id, as follows: 


CREATE VIEW hr_org_secure_view AS 

SELECT * FROM employees 

WHERE department_id = SYS_CONTEXT(‘hr_context’, 
'department_id'); 


DROP CONTEXT 


Use the DROP CONTEXT statement to remove a context namespace from 
the database. 


Removing a context namespace does not invalidate any context under that 
namespace that has been set for a user session. However, the context will be 
invalid when the user next attempts to set that context. 


You must have the DROP ANY CONTEXT system privilege. 
Examples 
Dropping an Application Context: Example 


The following statement drops the context: 
DROP CONTEXT hr_context; 


LIBRARY 


A library is a schema object associated with an operating-system shared 
library: For example a DLL. 


You can use the name of the library schema object in the call specification 
(call_spec) of aCREATE FUNCTION or CREATE PROCEDURE 
statements, or when declaring a function or procedure in a package or type, 
allowing the function, package, procedure, or type to invoke a 3GL code in 
the library. 


CREATE LIBRARY 


Use the CREATE LIBRARY statement to create a schema object associated 
with an operating-system shared library. The name of this schema object 
can then be used in the call_spec 

of CREATE FUNCTION or CREATE PROCEDURE statements, or when 
declaring a function or procedure in a package or type, so that SQL and 
PL/SQL can call to third-generation-language (3GL) functions and 
procedures. 


The CREATE LIBRARY statement is valid only on platforms that support 
shared libraries and dynamic linking. 


To create a library in your own schema, you must have 

the CREATE LIBRARY system privilege. To create a library in another 
user's schema, you must have the CREATE ANY LIBRARY system 
privilege. 


To use the library in the call_spec of aCREATE FUNCTION statement, 
or when declaring a function in a package or type, you must have 

the EXECUTE object privilege on the library and 

the CREATE FUNCTION system privilege. 


To use the library in the call_spec of aCREATE PROCEDURE statement, 
or when declaring a procedure in a package or type, you must have 

the EXECUTE object privilege on the library and 

the CREATE PROCEDURE system privilege. 


To execute a procedure or function defined with the call_spec (including a 
procedure or function defined within a package or type), you must have 

the EXECUTE object privilege on the procedure or function (but you do 
not need the EXECUTE object privilege on the library). 


ALTER LIBRARY 


The ALTER LIBRARY statement explicitly recompiles a library. Explicit 
recompilation eliminates the need for implicit run-time recompilation and 
prevents associated run-time compilation errors and performance overhead. 


If the library is in the SYS schema, you must be connected as SYSDBA. 
Otherwise, the library must be in your own schema or you must have 


the ALTER ANY LIBRARY system privilege. 

DROP LIBRARY 

Use the DROP LIBRARY statement to remove an external procedure 
library from the database. 

You must have the DROP ANY LIBRARY system privilege. 
Examples 

Dropping a Library: Example 

The following statement drops the ext_lib library: 


DROP LIBRARY ext_lib; 


TRIGGER 


A trigger is anamed PL/SQL block stored in the Oracle Database and 
executed automatically when a triggering event takes place. The event can 
be any of the following: A data manipulation language (DML) statement 
executed against a table e.g., INSERT, UPDATE, or DELETE. 


Triggers supplement the standard capabilities of Oracle to provide a highly 
customized database management system. For example, a trigger can 
restrict DML operations against a table to those issued during regular 
business hours. You can also use triggers to: Automatically generate derived 
column values. 


CREATE TRIGGER 


Triggers are defined using PL/SQL. Use the CREATE TRIGGER statement 
to create a database trigger , which is: 


A stored PL/SQL block associated with a table, a schema, or the 
database or 


- An anonymous PL/SQL block or a call to a procedure implemented in 
PL/SQL or Java 


Oracle Database automatically executes a trigger when specified conditions 
occur. 


To create a trigger in your own schema on a table in your own schema or on 
your own schema (SCHEMA), you must have 
the CREATE TRIGGER system privilege. 


To create a trigger in any schema on a table in any schema, or on another 
user's schema ( schema .SCHEMA), you must have 
the CREATE ANY TRIGGER system privilege. 


In addition to the preceding privileges, to create a trigger on DATABASE, 
you must have the ADMINISTER DATABASE TRIGGER system 
privilege. 

To create a trigger on a pluggable database (PDB), the current container 


must be that PDB and you must have 
the ADMINISTER DATABASE TRIGGER system privilege. 


In addition to the preceding privileges, to create a crossedition trigger, you 
must be enabled for editions. 


If the trigger issues SQL statements or calls procedures or functions, then 
the owner of the trigger must have the privileges necessary to perform these 
operations. These privileges must be granted directly to the owner rather 
than acquired through roles. 


ALTER TRIGGER 


Triggers are defined using PL/SQL. Use the ALTER TRIGGER statement 
to enable, disable, or compile a database trigger. 


The trigger must be in your own schema or you must 
have ALTER ANY TRIGGER system privilege. 


In addition, to alter a trigger on DATABASE, you must have 
the ADMINISTER DATABASE TRIGGER privilege. 


DROP TRIGGER 


Triggers are defined using PL/SQL. Use the DROP TRIGGER statement to 
remove a database trigger from the database. 


The trigger must be in your own schema or you must have 

the DROP ANY TRIGGER system privilege. To drop a trigger 
on DATABASE in another user's schema, you must also have 
the ADMINISTER DATABASE TRIGGER system privilege. 


Examples 
Dropping a Trigger: Example 


The following statement drops the salary_check trigger in the schema hr: 
DROP TRIGGER hr.salary_check; 


EDITION 


Since Oracle 11g release 2 the database now comes with Edition Based 
Redefinition. This technique provides you with the possibility to apply 
upgrades without invalidating the system. Before 11gR2, when you apply a 
change to the database, it might render a lot of objects to be invalid and you 
would need recompilation of your code. There are parts of the system that 
can be changed without this problem occuring, like the bodies of packages, 
but when you were to change the size of a column for instance, all the 
depending code needs to be checked and therefore needs to be recompiled. 
This could mean a problem for ‘running’ sessions, causing them to break. 
Using Edition Based Redefinition you can build the new or improved 
system and have users start using it without the ‘old’ system going down. 


CREATE EDITION 


This statement creates a new edition as a child of an existing edition. An 
edition makes it possible to have two or more versions of the same 
editionable objects in the database. When you create an edition, it 
immediately inherits all of the editionable objects of its parent edition. The 
following object types are editionable: 
Synonym 
e View 
Function 
e Procedure 
Package (specification and body) 
- Type (specification and body) 
Library 
Trigger 


An editionable object is an object of one of the above editionable object 
types in an editions-enabled schema. The ability to have multiple versions 
of these objects in the database greatly facilitates online application 
upgrades. 


Every newly created or upgraded Oracle Database has one default edition 
named ORA$BASE, which serves as the parent of the first edition created 
with a CREATE EDITION statement. You can subsequently designate a 
user-defined edition as the database default edition using 

an ALTER DATABASE DEFAULT EDITION statement. 


To create an edition, you must have the CREATE ANY EDITION system 
privilege, granted either directly or through a role. To create an edition as a 
child of another edition, you must have the USE object privilege on the 
parent edition. 


AS CHILD OF Clause 


If you use this clause, then the new edition is created as a child of 
parent_edition . If you omit this clause, then the new edition is created as a 
child of the leaf edition. At the time of its creation, the new edition inherits 
all editioned objects from its parent edition. 


Examples 


The following very simple examples are intended to show the syntax for 
creating and working with an edition. 


In the following statements, the user HR is given the privileges needed to 
create and use an edition: 


GRANT CREATE ANY EDITION, DROP ANY EDITION to HR; 
Grant succeeded. 


ALTER USER hr ENABLE EDITIONS; 
User altered. 


HR creates a new edition TEST_ED for testing purposes: 


CREATE EDITION test_ed; 


HR then creates an editioning view ed_view in the default 
edition ORASBASE for testing purposes, first verifying that the current 
edition is the default edition: 


SELECT SYS_CONTEXT(userenv’, 'current_edition_name') FROM 
DUAL; 
SYS_CONTEXT(‘USERENV','CURRENT_EDITION_NAME') 


ORASBASE 
1 row selected. 


CREATE EDITIONING VIEW e_view AS 
SELECT last_name, first_name, email FROM employees; 
View created. 


DESCRIBE e_view 


Name Null? Type 

LAST_NAME NOT NULL VARCHAR2(25) 
FIRST_NAME VARCHAR2(20) 
EMAIL NOT NULL VARCHAR2(25) 


The view is then actualized in the TEST_ED edition when HR uses 
the TEST_ED edition and re-creates the view in a different form: 


ALTER SESSION SET EDITION = TEST_ED; 
Session altered. 


CREATE OR REPLACE EDITIONING VIEW e_view AS 
SELECT last_name, first_name, email, salary FROM employees; 


View created. 


The view in the TEST_ED edition has an additional column: 


DESCRIBE e_view 


Name Null? Type 

LAST_NAME NOT NULL VARCHAR2(25) 
FIRST_NAME VARCHAR2(20) 
EMAIL NOT NULL VARCHAR2(25) 
SALARY NUMBER(8,2) 


The view in the ORA$BASE edition remains isolated from the test 
environment: 


ALTER SESSION SET EDITION = ora$base; 
Session altered. 


DESCRIBE e_view; 


Name Null? Type 

LAST_NAME NOT NULL VARCHAR2(25) 
FIRST_NAME VARCHAR2(20) 
EMAIL NOT NULL VARCHAR2(25) 


Even if the view is dropped in the test environment, it remains in 
the ORA$BASE edition: 


ALTER SESSION SET EDITION = TEST_ED; 
Session altered. 


DROP VIEW e_view; 
View dropped. 


ALTER SESSION SET EDITION = ORA$BASE; 
Session altered. 


DESCRIBE e_view; 


Name Null? Type 


LAST_NAME NOT NULL VARCHAR2(25) 
FIRST_NAME VARCHAR2(20) 
EMAIL NOT NULL VARCHAR2(25) 


When the testing of upgrade that necessitated the TEST_ED edition is 
complete, the edition can be dropped: 


DROP EDITION TEST_ED; 


DROP EDITION 


Use the DROP EDITION statement to drop an edition, along with all actual 
editionable objects it contains. An actual editionable object is an editionable 
object that has been created or modified in an edition. 


You must have the DROP ANY EDITION system privilege, granted either 
directly or through a role. 


JAVA 


Oracle Database provides support for developing, storing, and deploying 
Java applications. You can develop server-side Java applications that take 
advantage of the scalability and performance of Oracle Database. 


You can write and load Java applications within the database because it is a 
safe language with a lot of security features. Java has been developed to 
prevent anyone from tampering with the operating system where the Java 
code resides in. Some languages, such as C, can introduce security 
problems within the database. However, Java, because of its design, is a 
robust language that can be used within the database. 


Although the Java language presents many advantages to developers, 
providing an implementation of a JVM that supports Java server 
applications in a scalable manner is a challenge. 


CREATE JAVA 


Use the CREATE JAVA statement to create a schema object containing a 
Java source, class, or resource. 


To create or replace a schema object containing a Java source, class, or 
resource in your own schema, you must 

have CREATE PROCEDURE system privilege. To create or replace such a 
schema object in another user's schema, you must 

have CREATE ANY PROCEDURE system privilege. 


Examples 
Creating a Java Class Object: Example 


The following statement creates a schema object containing a Java class 
using the name found in a Java binary file: 


CREATE JAVA CLASS USING BFILE (java_dir, 'Agent.class') 
/ 


This example assumes the directory object java_dir, which points to the 
operating system directory containing the Java class Agent.class, already 


exists. In this example, the name of the class determines the name of the 
Java class schema object. 


Creating a Java Source Object: Example 


The following statement creates a Java source schema object: 


CREATE JAVA SOURCE NAMED "Welcome" AS 
public class Welcome { 
public static String welcome() { 
return "Welcome World"; } } 


Creating a Java Resource Object: Example 


The following statement creates a Java resource schema object 
named apptext from a bfile: 


CREATE JAVA RESOURCE NAMED "appText" 
USING BFILE (java_dir, 'textBundle.dat’) 
/ 


ALTER JAVA 


Use the ALTER JAVA statement to force the resolution of a Java class 
schema object or compilation of a Java source schema object. (You cannot 
call the methods of a Java class before all its external references to Java 
names are associated with other classes.) 


The Java source or class must be in your own schema, or you must have 
the ALTER ANY PROCEDURE system privilege. You must also have 
the EXECUTE object privilege on Java classes. 


JAVA SOURCE 

Use ALTER JAVA SOURCE to compile a Java source schema object. 
JAVA CLASS 

Use ALTER JAVA CLASS to resolve a Java class schema object. 


object_name 


Specify a previously created Java class or source schema object. Use double 
quotation marks to preserve lower- or mixed-case names. 


RESOLVER 


The RESOLVER clause lets you specify how schemas are searched for 
referenced fully specified Java names, using the mapping pairs specified 
when the Java class or source was created. 


RESOLVE | COMPILE 


RESOLVE and COMPILE are synonymous keywords. They let you specify 
that Oracle Database should attempt to resolve the primary Java class 
schema object. 


e When applied to a class, resolution of referenced names to other class 
schema objects occurs. 


When applied to a source, source compilation occurs. 
Examples 
Resolving a Java Class: Exampl e 


The following statement forces the resolution of a Java class: 


ALTER JAVA CLASS "Agent" 
RESOLVER (("/usr/bin/bfile_dir/*" pm)(* public)) 
RESOLVE; 


DROP JAVA 


Use the DROP JAVA statement to drop a Java source, class, or resource 
schema object. 


The Java source, class, or resource must be in your own schema or you 
must have the DROP ANY PROCEDURE system privilege. You also must 
have the EXECUTE object privilege on Java classes to use this command. 


Examples 
Dropping a Java Class Object: Example 


The following statement drops the Java class Agent: 


DROP JAVA CLASS "Agent"; 


GRANT 
Use the GRANT statement to grant: 


- System privileges to users and roles. 


Roles to users, roles, and program units. The granted roles can be 
either user-defined (local or external) or predefined. 


- Object privileges for a particular object to users and roles. 
Notes on Authorizing Database Users 


You can authorize database users through means other than the database and 
the GRANT statement. 


e Many Oracle Database privileges are granted through supplied 
PL/SQL and Java packages. For information on those privileges, refer 
to the documentation for the appropriate package. 


Some operating systems have facilities that let you grant roles to 
Oracle Database users with the initialization parameter OS_ROLES. 
If you choose to grant roles to users through operating system 
facilities, then you cannot also grant roles to users with 

the GRANT statement, although you can use the GRANT statement 
to grant system privileges to users and system privileges and roles to 
other roles. 


Note on Oracle Automatic Storage Management 


A user authenticated AS SYSASM can use this statement to grant the 
system privileges SYSASM, SYSOPER, and SYSDBA to a user in the 
Oracle ASM password file of the current node. 


To grant a system privilege , one of the following conditions must be met: 


- You must have been granted the GRANT ANY PRIVILEGE system 
privilege. In this case, if you grant the system privilege to a role, then 
a user to whom the role has been granted does not have the privilege 
unless the role is enabled in user's session. 


You must have been granted the system privilege with 

the ADMIN OPTION. In this case, if you grant the system privilege 
to a role, then a user to whom the role has been granted has the 
privilege regardless whether the role is enabled in the user's session. 


To grant a role to a user or another role , you must have been directly 
granted the role with the ADMIN OPTION, or you must have been granted 
the GRANT ANY ROLE system privilege, or you must have created the 
role. 


To grant a role to a program unit in your own schema , you must have 
been directly granted the role with either the ADMIN OPTION or 

the DELEGATE OPTION, or you must have been granted 

the GRANT ANY ROLE system privilege, or you must have created the 
role. 


To grant a role to a program unit in another user's schema , you must be 
the user SYS and the role must have been created by the schema owner or 
directly granted to the schema owner. 


To grant an object privilege on a user , by specifying 

the ON USER clause of the on_object_clause , you must be the user on 
whom the privilege is granted, or you must have been granted the object 
privilege on that user with the WITH GRANT OPTION, or you must have 
been granted the GRANT ANY OBJECT PRIVILEGE system privilege. If 
you can grant an object privilege on a user only because you have 

the GRANT ANY OBJECT PRIVILEGE, then the GRANTOR column of 
the *_TAB_PRIVS views displays the user on whom the privilege is 
granted rather than the user who issued the GRANT statement. 


To grant an object privilege on all other types of objects , you must own 
the object, or the owner of the object must have granted you the object 
privileges with the WITH GRANT OPTION, or you must have been 
granted the GRANT ANY OBJECT PRIVILEGE system privilege. If you 
have the GRANT ANY OBJECT PRIVILEGE, then you can grant the 
object privilege only if the object owner could have granted the same object 
privilege. In this case, the GRANTOR column of the *_TAB_PRIVS views 
displays the object owner rather than the user who issued 

the GRANT statement. 


To specify the CONTAINER clause, you must be connected to a 
multitenant container database (CDB). To specify CONTAINER = ALL, the 
current container must be the root. 


Examples 
Granting a System Privilege to a User: Example 


To grant the CREATE SESSION system privilege to the sample user hr, 
allowing hr to log on to Oracle Database, issue the following statement: 


GRANT CREATE SESSION 
TO hr; 


Assigning User Passwords When Granting a System Privilege: 
Example 


Assume that user hr exists and user newuser does not exist. The following 
statement resets the user hr password to password1 , creates 

user newuser with password2 , and grants both users 

the CREATE SESSION system privilege: 


GRANT CREATE SESSION 
TO hr, newuser IDENTIFIED BY password1 , password2 ; 


Granting System Privileges to a Role: Example 


The following statement grants appropriate system privileges to a data 
warehouse manager role: 


GRANT 
CREATE ANY MATERIALIZED VIEW 
, ALTER ANY MATERIALIZED VIEW 
, DROP ANY MATERIALIZED VIEW 
, QUERY REWRITE 
, GLOBAL QUERY REWRITE 
TO dw_manager 
WITH ADMIN OPTION; 


The dw_manager privilege domain now contains the system privileges 
related to materialized views. 


Granting a Role with the ADMIN OPTION: Example 


To grant the dw_manager role with the ADMIN OPTION to the sample 
user sh, issue the following statement: 


GRANT dw_manager 
TO sh 
WITH ADMIN OPTION; 


User sh can now perform the following operations with 
the dw_manager role: 


Enable the role and exercise any privileges in the privilege domain of 
the role, including the CREATE MATERIALIZED VIEW system 
privilege 

- Grant and revoke the role to and from other users 
Drop the role 

- Grant and revoke the dw_manager role to and from program units in 
the sh schema 

Granting a Role with the DELEGATE OPTION: Example 


To grant the dw_manager role with the DELEGATE OPTION to the sample 
user sh, issue the following statement: 


GRANT dw_manager 
TO sh 
WITH DELEGATE OPTION; 


User sh can now grant and revoke the dw_manager role to and from 
program units in the sh schema. 


Granting Object Privileges to a Role: Example 


The following example grants the SELECT object privileges to a data 
warehouse user role: 


GRANT SELECT ON sh.sales TO warehouse_user; 


Granting a Role to a Role: Example 


The following statement grants the warehouse_user role to 
the dw_manager role: 


GRANT warehouse_user TO dw_manager; 


The dw_manager role now contains all of the privileges in the domain of 
the warehouse_user role. 


Granting an Object Privilege on a User: Example 


To grant the INHERIT PRIVILEGES object privilege on user sh to user hr, 
issue the following statement: 


GRANT INHERIT PRIVILEGES ON USER sh TO hr; 
Granting an Object Privilege on a Directory: Example 
To grant READ on directory bfile_dir to user hr, with 


the GRANT OPTION, issue the following statement: 


GRANT READ ON DIRECTORY bfile_dir TO hr 
WITH GRANT OPTION; 


Granting Object Privileges on a Table to a User: Example 
To grant all privileges on the table oe.bonuses, to the user hr with 
the GRANT OPTION, issue the following statement: 


GRANT ALL ON bonuses TO hr WITH GRANT OPTION; 


The user hr can subsequently perform the following operations: 


Exercise any privilege on the bonuses table 
- Grant any privilege on the bonuses table to another user or role 
Granting Object Privileges on a View: Example 


To grant SELECT and UPDATE privileges on the view emp_view, to all 
users, issue the following statement: 


GRANT SELECT, UPDATE ON emp_view TO PUBLIC; 


All users can subsequently query and update the view of employee details. 
Granting Object Privileges to a Sequence in Another Schema: Example 


To grant SELECT privilege on the customers_seg sequence in the 
schema oe to the user hr, issue the following statement: 


GRANT SELECT ON oe.customers_seq TO hr; 


The user hr can subsequently generate the next value of the sequence with 
the following statement: 


SELECT oe.customers_seq.NEXTVAL FROM DUAL; 


Granting Multiple Object Privileges on Individual Columns: Example 


To grant to user oe the REFERENCES privilege on 

the employee_id column and the UPDATE privilege on 

the employee_id, salary, and commission_pct columns of 

the employees table in the schema hr, issue the following statement: 


GRANT REFERENCES (employee_id), 
UPDATE (employee_id, salary, commission_pct) 
ON hr.employees 
TO oe; 


The user oe can subsequently update values of the employee_id, salary, 
and commission_pct columns. User oe can also define referential integrity 
constraints that refer to the employee_id column. However, because 

the GRANT statement lists only these columns, oe cannot perform 
operations on any of the other columns of the employees table. 


For example, oe can create a table with a constraint: 


CREATE TABLE dependent 
(dependno NUMBER, 
dependname VARCHAR2(10), 
employee NUMBER 
CONSTRAINT in_emp REFERENCES hr.employees(employee_id) 


); 


The constraint in_emp ensures that all dependents in the dependent table 
correspond to an employee in the employees table in the schema hr. 


REVOKE 
Use the REVOKE statement to: 


Revoke system privileges from users and roles 
- Revoke roles from users, roles, and program units. 


Revoke object privileges for a particular object from users and roles 
Note on Oracle Automatic Storage Management 


A user authenticated AS SYSASM can use this statement to revoke the 
system privileges SYSASM, SYSOPER, and SYSDBA from a user in the 
Oracle ASM password file of the current node. 


To revoke a system privilege, you must have been granted the privilege 
with the ADMIN OPTION. You can revoke any privilege if you have 
the GRANT ANY PRIVILEGE system privilege. 


To revoke a role from a user or another role , you must have been 
directly granted the role with the ADMIN OPTION or you must have 
created the role. You can revoke any role if you have 

the GRANT ANY ROLE system privilege. 


To revoke a role from a program unit , you must be the user SYS or you 
must be the schema owner of the program unit. 


To revoke an object privilege , one of the following conditions must be 
met: 


You must previously have granted the object privilege to the user or 
role. 


You must have the GRANT ANY OBJECT PRIVILEGE system 
privilege. In this case, you can revoke any object privilege that was 
granted by the object owner or on behalf of the owner by a user with 
the GRANT ANY OBJECT PRIVILEGE. However, you cannot 
revoke an object privilege that was granted by way of 

a WITH GRANT OPTION grant. 


The REVOKE statement can revoke only privileges and roles that were 
previously granted directly with aGRANT statement. You cannot use this 
statement to revoke: 


- Privileges or roles not granted to the revokee 
Roles or object privileges granted through the operating system 
Privileges or roles granted to the revokee through roles 


To specify the CONTAINER clause, you must be connected to a 
multitenant container database (CDB). To specify CONTAINER = ALL, the 
current container must be the root. 


Examples 
Revoking a System Privilege from a User: Example 


The following statement revokes the DROP ANY TABLE system privilege 
from the users hr and oe: 


REVOKE DROP ANY TABLE FROM hr, oe; 


The users hr and oe can no longer drop tables in schemas other than their 
Own. 


Revoking a Role from a User: Example 


The following statement revokes the role dw_manager from the user sh: 
REVOKE dw_manager FROM sh; 


The user sh can no longer enable the dw_manager role. 
Revoking a System Privilege from a Role: Example 


The following statement revokes the CREATE TABLESPACE system 
privilege from the dw_manager role: 


REVOKE CREATE TABLESPACE FROM dw_manager; 


Enabling the dw_manager role no longer allows users to create tablespaces. 
Revoking a Role from a Role: Example 


To revoke the role dw_user from the role dw_manager, issue the following 
statement: 


REVOKE dw_user FROM dw_manager; 


The dw_user role privileges are no longer granted to dw_manager. 
Revoking an Object Privilege from a User: Example 


You can grant DELETE, INSERT, READ, SELECT, 
and UPDATE privileges on the table orders to the user hr with the following 
statement: 


GRANT ALL ON orders TO hr; 


To revoke the DELETE privilege on orders from hr, issue the following 
statement: 


REVOKE DELETE ON orders FROM hr; 


Revoking All Object Privileges from a User: Example 


To revoke the remaining privileges on orders that you granted to hr, issue 
the following statement: 


REVOKE ALL ON orders FROM hr; 


Revoking Object Privileges from PUBLIC: Example 


You can grant SELECT and UPDATE privileges on the 
view emp_details_view to all users by granting the privileges to the 
role PUBLIC: 


GRANT SELECT, UPDATE ON emp_details_view TO public; 


The following statement revokes UPDATE privilege 
on emp_details_view from all users: 


REVOKE UPDATE ON emp_details_view FROM public; 


Users can no longer update the emp_details_view view, although users can 
still query it. However, if you have also granted the UPDATE privilege 

on emp_details_view to any users, either directly or through roles, then 
these users retain the privilege. 


Revoking an Object Privilege on a User from a User: Example 
You can grant the user hr the INHERIT PRIVILEGES privilege on 


user sh with the following statement: 


GRANT INHERIT PRIVILEGES ON USER sh TO hr; 


To revoke the INHERIT PRIVILEGES privilege on user sh from user hr, 
issue the following statement: 


REVOKE INHERIT PRIVILEGES ON USER sh FROM hr; 


Revoking an Object Privilege on a Sequence from a User: Example 


You can grant the user oe the SELECT privilege on 
the departments_seq sequence in the schema hr with the following 
statement: 


GRANT SELECT ON hr.departments_seq TO oe; 


To revoke the SELECT privilege on departments_seq from oe, issue the 
following statement: 


REVOKE SELECT ON hr.departments_seq FROM oe; 


However, if the user hr has also granted SELECT privilege 
on departments to sh, then sh can still use departments by virtue of hr's 
grant. 


Revoking an Object Privilege with CASCADE CONSTRAINTS: 
Example 


You can grant to oe the privileges REFERENCES and UPDATE on 
the employees table in the schema hr with the following statement: 


GRANT REFERENCES, UPDATE ON hr.employees TO oe; 


The user oe can exercise the REFERENCES privilege to define a constraint 
in his or her own dependent table that refers to the employees table in the 
schema hr: 


CREATE TABLE dependent 
(dependno NUMBER, 
dependname VARCHAR2(10), 
employee NUMBER 
CONSTRAINT in_emp REFERENCES 
hr.employees(employee_id) ); 


You can revoke the REFERENCES privilege on hr.employees from oe by 
issuing the following statement that contains 
the CASCADE CONSTRAINTS clause: 


REVOKE REFERENCES 
ON hr.employees 
FROM oe 
CASCADE CONSTRAINTS; 


Revoking oe's REFERENCES privilege on hr.employees causes Oracle 
Database to drop the in_emp constraint, because oe required the privilege to 
define the constraint. 


However, if oe has also been granted the REFERENCES privilege 

on hr.employees by a user other than you, then the database does not drop 
the constraint. oe still has the privilege necessary for the constraint by virtue 
of the other user's grant. 


Revoking an Object Privilege on a Directory from a User: Example 


You can revoke the READ object privilege on directory bfile_dir from hr by 
issuing the following statement: 


REVOKE READ ON DIRECTORY bfile_dir FROM hr; 


Revoke Operations that Use GRANT ANY OBJECT PRIVILEGE: 
Example 


Suppose that the database administrator has 
granted GRANT ANY OBJECT PRIVILEGE to user sh. Now suppose that 
user hr grants the update privilege on the employees table to oe: 


CONNECT hr 
GRANT UPDATE ON employees TO oe WITH GRANT OPTION; 


This grant gives user oe the right to pass the object privilege along to 
another user: 


CONNECT oe 
GRANT UPDATE ON hr.employees TO pm; 


User sh, who has the GRANT ANY OBJECT PRIVILEGE, can now act on 
behalf of user hr and revoke the update privilege from user oe, 
because oe was granted the privilege by hr: 


CONNECT sh 
REVOKE UPDATE ON hr.employees FROM oe; 


User sh cannot revoke the update privilege from user pm explicitly, 
because pm received the grant neither from the object owner (hr), nor 
from sh, nor from another user with GRANT ANY OBJECT PRIVILEGE, 
but from user oe. However, the preceding statement cascades, removing all 
privileges that depend on the one revoked. Therefore the object privilege is 
implicitly revoked from pm as well. 


PURGE 
Use the PURGE statement to: 
- Remove a table or index from your recycle bin and release all of the 
space associated with the object 


Remove part or all of a dropped tablespace or tablespace set from the 
recycle bin 


Remove the entire recycle bin 
To see the contents of your recycle bin, query 
the USER_RECYCLEBIN data dictionary view. You can use 


the RECYCLEBIN synonym instead. The following two statements return 
the same rows: 


SELECT * FROM RECYCLEBIN; 
SELECT * FROM USER_RECYCLEBIN; 


To purge a table, the table must reside in your own schema or you must 
have the DROP ANY TABLE system privilege, or you must have 
the SYSDBA system privilege. 


To purge an index, the index must reside in your own schema or you must 
have the DROP ANY INDEX system privilege, or you must have 
the SYSDBA system privilege. 


To purge a tablespace or tablespace set, you must have 
the DROP TABLESPACE system privilege, or you must have 
the SYSDBA system privilege. 


To purge a tablespace set, you must also be connected to a shard catalog 
database as an SDB user. 


To perform the PURGE DBA_RECYCLEBIN operation, you must have 
the SYSDBA or PURGE DBA_RECYCLEBIN system privilege. 


Examples 
Remove a File From Your Recycle Bin: Example 


The following statement removes the table test from the recycle bin. If more 
than one version of test resides in the recycle bin, then Oracle Database 
removes the version that has been there the longest: 


PURGE TABLE test; 


To determine system-generated name of the table you want removed from 
your recycle bin, issue a SELECT statement on your recycle bin. Using that 
object name, you can remove the table by issuing a statement similar to the 
following statement. (The system-generated name will differ from the one 
shown in the example.) 


PURGE TABLE RB$$33750$TABLESO; 


Remove the Contents of Your Recycle Bin: Example 


To remove the entire contents of your recycle bin, issue the following 
statement: 


PURGE RECYCLEBIN; 


RENAME 
Use the RENAME statement to rename a table, view, sequence, or private 
synonym. 
Oracle Database automatically transfers integrity constraints, indexes, 
and grants on the old object to the new object. 


Oracle Database invalidates all objects that depend on the renamed 
object, such as views, synonyms, and stored procedures and functions 
that refer to a renamed table. 


The object must be in your own schema. 
Examples 
Renaming a Database Object: Example 


The following example uses a copy of the sample table hr.departments. To 
change the name of table departments_new to emp_departments, issue the 
following statement: 


RENAME departments_new TO emp_departments; 


You cannot use this statement directly to rename columns. However, you 
can rename a column using the ALTER TABLE ... rename_column_clause 


Another way to rename a column is to use the RENAME statement together 
with the CREATE TABLE statement with AS subquery . This method is 
useful if you are changing the structure of a table rather than only renaming 
a column. The following statements re-create the sample 

table hr.job_history, renaming a column from department_id to dept_id: 


CREATE TABLE temporary 
(employee_id, start_date, end_date, job_id, dept_id) 


AS SELECT 
employee_id, start_date, end_date, job_id, department_id 
FROM job_history; 


DROP TABLE job_history; 


RENAME temporary TO job_history; 


Any integrity constraints defined on table job_history will be lost in the 
preceding example. You will have to redefine them on the 
new job_history table using an ALTER TABLE statement. 


TRUNCATE TABLE 


Use the TRUNCATE TABLE statement to remove all rows from a table. By 
default, Oracle Database also performs the following tasks: 


- Deallocates all space used by the removed rows except that specified 
by the MINEXTENTS storage parameter 
Sets the NEXT storage parameter to the size of the last extent 
removed from the segment by the truncation process 
Removing rows with the TRUNCATE TABLE statement can be more 
efficient than dropping and re-creating a table. Dropping and re-creating a 
table invalidates dependent objects of the table, and requires you to repeat 
the following actions: 
Grant object privileges on the table 
- Create the indexes, integrity constraints, and triggers on the table 
Specify the storage parameters of the table 
Truncating has none of these effects. 
Removing rows with the TRUNCATE TABLE statement can be faster than 


removing all rows with the DELETE statement, especially if the table has 
numerous triggers, indexes, and other dependencies. 


To truncate a table, the table must be in your schema or you must have 
the DROP ANY TABLE system privilege. 


To specify the CASCADE clause, all affected child tables must be in your 
schema or you must have the DROP ANY TABLE system privilege. 


You can truncate a private temporary table with the existing TRUNCATE 
TABLE command. Truncating a private temporary table will not commit 
and existing transaction. This applies to both transaction-specific and 
session-specific private temporary tables. Note that a truncated private 
temporary table will not go into the RECYCLEBIN. 


TABLE Clause 


Specify the schema and name of the table to be truncated. This table cannot 
be part of a cluster. If you omit schema , then Oracle Database assumes the 
table is in your own schema. 


You can truncate index-organized tables and temporary tables. When 
you truncate a temporary table, only the rows created during the 
current session are removed. 


Oracle Database changes the NEXT storage parameter of table to be 
the size of the last extent deleted from the segment in the process of 
truncation. 


Oracle Database also automatically truncates and resets any 
existing UNUSABLE indicators for the following indexes on table: 
range and hash partitions of local indexes and subpartitions of local 
indexes. 


If table is not empty, then the database marks UNUSABLE all 
nonpartitioned indexes and all partitions of global partitioned indexes 
on the table. However, when the table is truncated, the index is also 
truncated, and a new high water mark is calculated for the index 
segment. This operation is equivalent to creating a new segment for 
the index. Therefore, at the end of the truncate operation, the indexes 
are once again USABLE. 


For a domain index, this statement invokes the appropriate truncate 
routine to truncate the domain index data. 


If a regular or index-organized table contains LOB columns, then all 
LOB data and LOB index segments are truncated. 

If table is partitioned, then all partitions or subpartitions, as well as 
the LOB data and LOB index segments for each partition or 
subpartition, are truncated. 


All cursors are invalidated. 


MATERIALIZED VIEW LOG Clause 


The MATERIALIZED VIEW LOG clause lets you specify whether a 
materialized view log defined on the table is to be preserved or purged 
when the table is truncated. This clause permits materialized view master 
tables to be reorganized through export or import without affecting the 
ability of primary key materialized views defined on the master to be fast 
refreshed. To support continued fast refresh of primary key materialized 
views, the materialized view log must record primary key information. 


PRESERVE 


Specify PRESERVE if any materialized view log should be preserved when 
the master table is truncated. This is the default. 


PURGE 


Specify PURGE if any materialized view log should be purged when the 
master table is truncated. 


STORAGE Clauses 


The STORAGE clauses let you determine what happens to the space freed 
by the truncated rows. 

The DROP STORAGE clause, DROP ALL STORAGE clause, 

and REUSE STORAGE clause also apply to the space freed by the data 
deleted from associated indexes. 


DROP STORAGE 


Specify DROP STORAGE to deallocate all space from the deleted rows 
from the table except the space allocated by the MINEXTENTS parameter 
of the table. This space can subsequently be used by other objects in the 
tablespace. Oracle Database also sets the NEXT storage parameter to the 
size of the last extent removed from the segment in the truncation process. 
This setting, which is the default, is useful for small and medium-sized 
objects. The extent management in locally managed tablespace is very fast 
in these cases, so there is no need to reserve space. 


DROP ALL STORAGE 


Specify DROP ALL STORAGE to deallocate all space from the deleted 
rows from the table, including the space allocated by 


the MINEXTENTS parameter. All segments for the table, as well as all 
segments for its dependent objects, will be deallocated. 


REUSE STORAGE 


Specify REUSE STORAGE to retain the space from the deleted rows 
allocated to the table. Storage values are not reset to the values when the 
table was created. This space can subsequently be used only by new data in 
the table resulting from insert or update operations. This clause leaves 
storage parameters at their current settings. 


This setting is useful as an alternative to deleting all rows of a very large 
table—when the number of rows is very large, the table entails many 
thousands of extents, and when data is to be reinserted in the future. 


This clause is not valid for temporary tables. A session becomes unbound 
from the temporary table when the table is truncated, so the storage is 
automatically dropped. 


If you have specified more than one free list for the object you are 
truncating, then the REUSE STORAGE clause also removes any mapping 
of free lists to instances and resets the high-water mark to the beginning of 
the first extent. 


CASCADE 


If you specify CASCADE, then Oracle Database truncates all child tables 
that reference table with an enabled ON DELETE CASCADE referential 
constraint. This is a recursive operation that will truncate all child tables, 
granchild tables, and so on, using the specified options. 


Examples 
Truncating a Table: Example 


The following statement removes all rows from a hypothetical copy of the 
sample table hr.employees and returns the freed space to the tablespace 
containing employees: 


TRUNCATE TABLE employees_demo; 


The preceding statement also removes all data from all indexes 
on employees and returns the freed space to the tablespaces containing 
them. 


Preserving Materialized View Logs After Truncate: Example 


The following statements are examples of TRUNCATE statements that 
preserve materialized view logs: 


TRUNCATE TABLE sales_demo PRESERVE MATERIALIZED 
VIEW LOG; 


TRUNCATE TABLE orders_demo; 


Data Manipulation Language (DML) Statements 


Data manipulation language (DML) statements access and manipulate data 
in existing schema objects. These statements do not implicitly commit the 
current transaction. The data manipulation language statements are: 


INSERT 
SELECT 
UPDATE 
DELETE 
e LOCK TABLE 
> MERGE 


INSERT 


Use the INSERT statement to add rows to a table, the base table of a view, a 
partition of a partitioned table or a subpartition of a composite-partitioned 
table, or an object table or the base table of an object view. 


For you to insert rows into a table, the table must be in your own schema or 
you must have the INSERT object privilege on the table. 


For you to insert rows into the base table of a view, the owner of the schema 
containing the view must have the INSERT object privilege on the base 
table. Also, if the view is in a schema other than your own, then you must 
have the INSERT object privilege on the view. 


If you have the INSERT ANY TABLE system privilege, then you can also 
insert rows into any table or the base table of any view. 


You must also have the READ or SELECT object privilege on the table into 
which you want to insert rows if the table is on a remote database. 


Conventional and Direct-Path INSERT 


You can use the INSERT statement to insert data into a table, partition, or 
view in two ways: conventional INSERT and direct-path INSERT. When 
you issue a conventional INSERT statement, Oracle Database reuses free 
space in the table into which you are inserting and maintains referential 
integrity constraints. With direct-path INSERT, the database appends the 
inserted data after existing data in the table. Data is written directly into 


data files, bypassing the buffer cache. Free space in the existing data is not 
reused. This alternative enhances performance during insert operations and 
is similar to the functionality of the Oracle direct-path loader utility, 
SQL*Loader. When you insert into a table that has been created in parallel 
mode, direct-path INSERT is the default. 


The manner in which the database generates redo and undo data depends in 
part on whether you are using conventional or direct-path INSERT: 


- Conventional INSERT always generates maximal redo and undo for 
changes to both data and metadata, regardless of the logging setting of 
the table and the archivelog and force logging settings of the database. 


- Direct-path INSERT generates both redo and undo for metadata 
changes, because these are needed for operation recovery. For data 
changes, undo and redo are generated as follows: 

o Direct-path INSERT always bypasses undo generation for data 
changes. 


o If the database is not 
in ARCHIVELOG or FORCE LOGGING mode, then no redo is 
generated for data changes, regardless of the logging setting of 
the table. 


o Ifthe database is in ARCHIVELOG mode (but not 
in FORCE LOGGING mode), then direct- 
path INSERT generates data redo for LOGGING tables but not 
for NOLOGGING tables. 


o If the database is in ARCHIVELOG and 
FORCE LOGGING mode, then direct-path SQL generate data 
redo for both LOGGING and NOLOGGING tables. 


Direct-path INSERT is subject to a number of restrictions. If any of these 
restrictions is violated, then Oracle Database executes 

conventional INSERT serially without returning any message, unless 
otherwise noted: 


- You can have multiple direct-path INSERT statements in a single 
transaction, with or without other DML statements. However, after 
one DML statement alters a particular table, partition, or index, no 


other DML statement in the transaction can access that table, 
partition, or index. 


Queries that access the same table, partition, or index are allowed 
before the direct-path INSERT statement, but not after it. 


- If any serial or parallel statement attempts to access a table that has 
already been modified by a direct-path INSERT in the same 
transaction, then the database returns an error and rejects the 
statement. 


The target table cannot be of a cluster. 
- The target table cannot contain object type columns. 


Direct-path INSERT is not supported for an index-organized table 
(IOT) if it has a mapping table, or if it is reference by a materialized 
view. 


- Direct-path INSERT into a single partition of an index-organized 
table (IOT), into a partitioned IOT with only one partition, or into an 
IOT that is not partitioned, will be done serially, even if the IOT was 
created in parallel mode or you specify 
the APPEND or APPEND_VALUES hint. However, direct- 
path INSERT operations into a partitioned IOT will honor parallel 
mode as long as the partition-extended name is not used and the IOT 
has more than one partition. 


The target table cannot have any triggers or referential integrity 
constraints defined on it. 


- The target table cannot be replicated. 
A transaction containing a direct-path INSERT statement cannot be or 
become distributed. 


You cannot query or modify direct-path inserted data immediately after the 
insert is complete. If you attempt to do so, an ORA-12838 error is 
generated. You must first issue a COMMIT statement before attempting to 
read or modify the newly-inserted data. 


Examples 
Inserting Values into Tables: Example s 


The following statement inserts a row into the sample table departments: 


INSERT INTO departments 
VALUES (280, ‘Recreation’, 121, 1700); 


If the departments table had been created with a default value of 121 for 
the manager_id column, then you could issue the same statement as 
follows: 


INSERT INTO departments 
VALUES (280, ‘Recreation’, DEFAULT, 1700); 


The following statement inserts a row with six columns into 
the employees table. One of these columns is assigned NULL and another is 
assigned a number in scientific notation: 


INSERT INTO employees (employee_id, last_name, email, 
hire_date, job_id, salary, commission_pct) 
VALUES (207, 'Gregory', 'pgregory@example.com'’, 
sysdate, 'PU_CLERK’, 1.2E3, NULL); 


The following statement has the same effect as the preceding example, but 
uses a subquery in the DML_table_expression_clause : 


INSERT INTO 
(SELECT employee_id, last_name, email, hire_date, job_id, 
salary, commission_pct FROM employees) 
VALUES (207, 'Gregory’, 'pgregory@example.com'’, 
sysdate, 'PU_CLERK’, 1.2E3, NULL); 


Inserting Values with a Subquery: Example 


The following statement copies employees whose commission exceeds 25% 
of their salary into the bonuses table: 


INSERT INTO bonuses 


SELECT employee_id, salary*1.1 
FROM employees 
WHERE commission_pct > 0.25; 


Inserting Into a Table with Error Logging: Example 


The following statements create a raises table in the sample schema hr, 
create an error logging table using the DBMS_ERRLOG package, and 
populate the raises table with data from the employees table. One of the 
inserts violates the check constraint on raises, and that row can be seen 
in errlog. If more than ten errors had occurred, then the statement would 
have aborted, rolling back any insertions made: 


CREATE TABLE raises (emp_id NUMBER, sal NUMBER 
CONSTRAINT check_sal CHECK(sal > 8000)); 


EXECUTE DBMS_ERRLOG.CREATE_ERROR_LOG(raises'’, 
'errlog'); 
INSERT INTO raises 
SELECT employee_id, salary*1.1 FROM employees 
WHERE commission_pct > .2 
LOG ERRORS INTO errlog (‘my_bad') REJECT LIMIT 10; 


SELECT ORA_ERR_MESG$, ORA_ERR_TAG$, emp_id, sal 
FROM errlog; 


ORA_ERR_MESG$ ORA_ERR_TAG$ EMP_ID SAL 


ORA-02290: check constraint my_bad 161 7700 
(HR.SYS_C004266) violated 


Inserting into a Remote Database: Example 
The following statement inserts a row into the employees table owned by 


the user hr on the database accessible by the database link remote: 


INSERT INTO employees@remote 


VALUES (8002, ‘Juan’, 'Fernandez’, 'juanf@example.com', NULL, 

TO_DATE(‘04-OCT-1992', 'DD-MON-YYYY’), 'SH_CLERK’, 
3000, 

NULL, 121, 20); 


Inserting Sequence Values: Example 


The following statement inserts a new row containing the next value of 
the departments_seq sequence into the departments table: 


INSERT INTO departments 
VALUES (departments_seq.nextval, 'Entertainment', 162, 1400); 


Inserting Using Bind Variables: Example 


The following example returns the values of the inserted rows into output 
bind variables :bnd1 and :bnd2. The bind variables must first be declared. 


INSERT INTO employees 
(employee_id, last_name, email, hire_date, job_id, salary) 
VALUES 
(employees_seq.nextval, 'Doe', 'john.doe@example.com', 
SYSDATE, 'SH_CLERK'’, 2400) 
RETURNING salary*12, job_id INTO :bnd1, :bnd2; 


Inserting into a Substitutable Tables and Columns: Examples 


The following example inserts into the persons table. The first statement 
uses the root type person_t. The second insert uses the employee_t subtype 
of person_t, and the third insert uses the part_time_emp_t subtype 

of employee_t: 


INSERT INTO persons VALUES (person_t('Bob', 1234)); 
INSERT INTO persons VALUES (employee_t(‘Joe', 32456, 12, 
100000)); 
INSERT INTO persons VALUES ( 

part_time_emp_t("Tim', 5678, 13, 1000, 20)); 


The following example inserts into the books table. Notice that 
specification of the attribute values is identical to that for the substitutable 
table example: 


INSERT INTO books VALUES ( 

'An Autobiography’, person_t(‘Bob', 1234)); 
INSERT INTO books VALUES ( 

‘Business Rules', employee_t(‘Joe’, 3456, 12, 10000)); 
INSERT INTO books VALUES ( 

‘Mixing School and Work', 

part_time_emp_t("Tim', 5678, 13, 1000, 20)); 


You can extract data from substitutable tables and columns using built-in 
functions and conditions. 


Inserting Using the TO_LOB Function: Example 


The following example copies LONG data to a LOB column in the 
following long_tab table: 


CREATE TABLE long_tab (pic_id NUMBER, long_pics LONG 
RAW); 


First you must create a table with a LOB. 
CREATE TABLE lob_tab (pic_id NUMBER, lob_pics BLOB); 


Next, use an INSERT ... SELECT statement to copy the data in all rows for 
the LONG column into the newly created LOB column: 


INSERT INTO lob_tab 
SELECT pic_id, TO_LOB(long_pics) FROM long_tab; 


When you are confident that the migration has been successful, you can 
drop the long_pics table. Alternatively, if the table contains other columns, 
then you can simply drop the LONG column from the table as follows: 


ALTER TABLE long_tab DROP COLUMN long _pics; 


Multitable Inserts: Examples 


The following example uses the multitable insert syntax to insert into the 
sample table sh.sales some data from an input table with a different 
structure. 


The input table looks like this: 


SELECT * FROM sales_input_table; 

PRODUCT_ID CUSTOMER_ID WEEKLY_ST SALES SUN 
SALES_MON SALES TUE SALES WED SALES_THU 
SALES_FRI SALES_SAT 


111 222 01-OCT-00 100 200 300 400 
500 600 700 

222 333 08-OCT-00 200 300 400 500 
600 700 800 

333 444 15-OCT-00 300 400 500 600 
700 800 900 


The multitable insert statement looks like this: 


INSERT ALL 
INTO sales (prod_id, cust_id, time_id, amount) 
VALUES (product_id, customer_id, weekly_start_date, sales_sun) 
INTO sales (prod_id, cust_id, time_id, amount) 
VALUES (product_id, customer_id, weekly_start_date+1, 
sales_mon) 


INTO sales (prod_id, cust_id, time_id, amount) 

VALUES (product_id, customer_id, weekly_start_date+2, 
sales_tue) 

INTO sales (prod_id, cust_id, time_id, amount) 

VALUES (product_id, customer_id, weekly_start_date+3, 
sales_wed) 

INTO sales (prod_id, cust_id, time_id, amount) 

VALUES (product_id, customer_id, weekly_start_date+4, 
sales_thu) 

INTO sales (prod_id, cust_id, time_id, amount) 

VALUES (product_id, customer_id, weekly_start_date+5, 
sales_fri) 

INTO sales (prod_id, cust_id, time_id, amount) 

VALUES (product_id, customer_id, weekly_start_date+6, 
Ssales_sat) 

SELECT product_id, customer_id, weekly_start_date, sales_sun, 
sales_mon, sales_tue, sales wed, sales thu, sales fri, sales_sat 
FROM sales_input_table; 


Assuming these are the only rows in the sales table, the contents now look 
like this: 


SELECT * FROM sales 
ORDER BY prod_id, cust_id, time_id; 


PROD_ID CUST_ID TIME ID C PROMO_ID 
QUANTITY_SOLD AMOUNT COST 


111 222 01-OCT-00 100 
111 222 02-OCT-00 200 
111 222 03-OCT-00 300 
111 222 04-OCT-00 400 
111 222 05-OCT-00 500 
111 222 06-OCT-00 600 
111 222 07-OCT-00 700 


222 333 08-OCT-00 200 


222 333 09-OCT-00 300 


222 333 10-OCT-00 400 
222 333 11-OCT-00 500 
222 333 12-OCT-00 600 
222 333 13-OCT-00 700 
222 333 14-OCT-00 800 
333 444 15-OCT-00 300 
333 444 16-OCT-00 400 
333 444 17-OCT-00 500 
333 444 18-OCT-00 600 
333 444 19-OCT-00 700 
333 444 20-OCT-00 800 
333 444 21-OCT-00 900 


The next examples insert into multiple tables. Suppose you want to provide 
to sales representatives some information on orders of various sizes. The 
following example creates tables for small, medium, large, and special 
orders and populates those tables with data from the sample table oe.orders: 


CREATE TABLE small_orders 
(order id NUMBER(12) NOT NULL, 
customer _id NUMBER(6) NOT NULL, 
order_total NUMBER(8,2), 
sales_rep_id NUMBER(6) 
); 


CREATE TABLE medium_orders AS SELECT * FROM 
small_orders; 


CREATE TABLE large_orders AS SELECT * FROM small_orders; 


CREATE TABLE special_orders 
(order_id NUMBER(12) NOT NULL, 
customer_id NUMBER(6) NOT NULL, 
order_total NUMBER(8,2), 
sales rep_id NUMBER(6), 


credit_limit NUMBER(9,2), 
cust_email VARCHAR2(40) 
); 


The first multitable insert populates only the tables for small, medium, and 
large orders: 


INSERT ALL 

WHEN order_total <= 100000 THEN 
INTO small_orders 

WHEN order_total > 1000000 AND order_total <= 200000 THEN 
INTO medium_orders 

WHEN order_total > 200000 THEN 
INTO large_orders 

SELECT order_id, order_total, sales_rep_id, customer_id 
FROM orders; 


You can accomplish the same thing using the ELSE clause in place of the 
insert into the large_orders table: 


INSERT ALL 

WHEN order_total <= 100000 THEN 
INTO small_orders 

WHEN order_total > 100000 AND order_total <= 200000 THEN 
INTO medium_orders 

ELSE 
INTO large_orders 

SELECT order_id, order_total, sales_rep_id, customer_id 
FROM orders; 


The next example inserts into the small, medium, and large tables, as in the 
preceding example, and also puts orders greater than 290,000 into 

the special_orders table. This table also shows how to use column aliases to 
simplify the statement: 


INSERT ALL 
WHEN ottl <= 100000 THEN 
INTO small_orders 
VALUES (oid, ottl, sid, cid) 
WHEN ottl > 100000 and ottl <= 200000 THEN 
INTO medium_orders 
VALUES (oid, ottl, sid, cid) 
WHEN ottl > 200000 THEN 
into large_orders 
VALUES (oid, ottl, sid, cid) 
WHEN ottl > 290000 THEN 
INTO special_orders 
SELECT o.order_id oid, o.customer_id cid, o.order_total ottl, 
o.sales_rep_id sid, c.credit_limit cl, c.cust_email cem 
FROM orders o, customers c 
WHERE o.customer_id = c.customer_id; 


Finally, the next example uses the FIRST clause to put orders greater than 
290,000 into the special_orders table and exclude those orders from 
the large_orders table: 


INSERT FIRST 
WHEN ottl <= 100000 THEN 
INTO small_orders 
VALUES (oid, ottl, sid, cid) 
WHEN ottl > 100000 and ottl <= 200000 THEN 
INTO medium_orders 
VALUES (oid, ottl, sid, cid) 
WHEN ottl > 290000 THEN 
INTO special_orders 
WHEN ottl > 200000 THEN 
INTO large_orders 
VALUES (oid, ottl, sid, cid) 
SELECT o.order_id oid, o.customer_id cid, o.order_total ottl, 
o.sales_rep_id sid, c.credit_limit cl, c.cust_email cem 
FROM orders o, customers c 


WHERE o.customer_id = c.customer_id; 


Inserting Multiple Rows Using a Single Statement: Example 


The following statements create three tables named people, patients and 
staff: 


CREATE TABLE people ( 
person_id INTEGER NOT NULL PRIMARY KEY, 
given_name VARCHAR2(100) NOT NULL, 
family_name VARCHAR2(100) NOT NULL, 
title ©VARCHAR2(20), 

birth_date DATE 


); 


CREATE TABLE patients ( 

patient_id INTEGER NOT NULL PRIMARY KEY 
REFERENCES people (person_id), 
last_admission_date DATE 


); 


CREATE TABLE staff ( 
staff_id INTEGER NOT NULL PRIMARY KEY REFERENCES 
people (person_id), 
hired_date DATE 
); 


The following statement inserts a row into the people table: 


INSERT INTO people 
VALUES (1, 'Dave', 'Badger', 'Mr', date'1960-05-01'); 


The following statement returns an error as there is no value provided for 
the birth_date column: 


INSERT INTO people 


VALUES (2, 'Simon’, 'Fox', 'Mr'); 
The following statement inserts a row into the people table: 


INSERT INTO people (person_id, given_name, family_name, title) 
VALUES (2, 'Simon’, 'Fox', 'Mr'); 


The following statement inserts a row into the people table and the value for 
the title column is populated by selecting a static value from the dual table: 


INSERT INTO people (person_id, given_name, family_name, title) 
VALUES (3, 'Dave', 'Frog', (SELECT 'Mr' FROM dual)); 


The following statement inserts multiple rows into the people table using 
‘SELECT’ statement: 


INSERT INTO people (person_id, given_name, family_name, title) 
WITH names AS ( 
SELECT 4, 'Ruth', 'Fox', ‘Mrs’ FROM dual UNION ALL 
SELECT 5, ‘Isabelle’, 'Squirrel', 'Miss' FROM dual UNION ALL 
SELECT 6, ‘Justin’, ‘Frog’, ‘Master’ FROM dual UNION ALL 
SELECT 7, 'Lisa’, ‘Owl’, ‘Dri’ FROM dual 


) 
SELECT * FROM names; 
The following statement rolls back all the previous DML operations: 
ROLLBACK; 


The following statement inserts multiple rows into the people table using 
‘SELECT?’ statement with a ‘WHERE’ condition: 


INSERT INTO people (person_id, given_name, family_name, title) 
WITH names AS ( 


SELECT 4, 'Ruth', 'Fox'family_name, ‘Mrs' FROM dual 
UNION ALL 
SELECT 5, 'Isabelle’, 'Squirrel' family_name, 'Miss' FROM dual 
UNION ALL 
SELECT 6, ‘Justin’, 'Frog'family_name, 'Master' FROM dual 
UNION ALL 
SELECT 7, 'Lisa', ‘Owl'family_name, 'Dr' FROM dual 
) 
SELECT * FROM names 
WHERE family_name LIKE 'F%'; 


The following statement rolls back all the previous DML operations: 
ROLLBACK; 


The following statement inserts multiple rows into people, patients and staff 
table using ‘INSERT ALL’ statement: 


INSERT ALL 
/* Every one is a person */ 
INTO people (person_id, given_name, family_name, title) 
VALUES (id, given_name, family_name, title) 
INTO patients (patient_id, last_admission_date) 
VALUES (id, admission_date) 
INTO staff (staff_id, hired_date) 
VALUES (id, hired_date) 
WITH names AS ( 
SELECT 4 id, "Ruth' given_name, 'Fox' family_name, 'Mrs' title, 
NULL hired_date, DATE'2009-12-31' admission_date 
FROM dual UNION ALL 
SELECT 5 id, Isabelle’ given_name, 'Squirrel' family_name, 'Miss' 
title , 
NULL hired_date, DATE'2014-01-01' admission_date 
FROM dual UNION ALL 
SELECT 6 id, ‘Justin’ given_name, 'Frog' family_name, 'Master' 
title, 


NULL hired_date, DATE'2015-04-22' admission_date 
FROM dual UNION ALL 
SELECT 7 id, 'Lisa' given_name, 'Owl' family_name, 'Dr' title, 
DATE'2015-01-01' hired_date, NULL admission_date 
FROM dual 


) 
SELECT * FROM names; 


The following statement rolls back all the previous DML operations: 
ROLLBACK; 


The following statement inserts multiple rows into people, patients and staff 
table using ‘INSERT ALL’ statement with various conditions: 


INSERT ALL 
/* Everyone is a person, so insert all rows into people */ 
WHEN 1=1 THEN 
INTO people (person_id, given_name, family_name, title) 
VALUES (id, given_name, family_name, title) 
/* Only people with an admission date are patients */ 
WHEN admission_date IS NOT NULL THEN 
INTO patients (patient_id, last_admission_date) 
VALUES (id, admission_date) 
/* Only people with a hired date are staff */ 
WHEN hired_date IS NOT NULL THEN 
INTO staff (staff_id, hired_date) 
VALUES (id, hired_date) 
WITH names AS ( 
SELECT 4 id, "Ruth' given_name, 'Fox' family_name, 'Mrs' title, 
NULL hired_date, DATE'2009-12-31' admission_date 
FROM dual UNION ALL 
SELECT 5 id, Isabelle’ given_name, 'Squirrel' family_name, 'Miss' 
title , 
NULL hired_date, DATE'2014-01-01' admission_date 
FROM dual UNION ALL 


SELECT 6 id, ‘Justin’ given_name, 'Frog' family_name, 'Master' 
title, 
NULL hired_date, DATE'2015-04-22' admission_date 
FROM dual UNION ALL 
SELECT 7 id, 'Lisa' given_name, 'Owl' family_name, 'Dr' title, 
DATE'2015-01-01' hired_date, NULL admission_date 
FROM dual 


) 
SELECT * FROM names; 


SELECT 


Use a SELECT statement or subquery to retrieve data from one or more 
tables, object tables, views, object views, materialized views, analytic 
views, or hierarchies. 


If part or all of the result of a SELECT statement is equivalent to an 
existing materialized view, then Oracle Database may use the materialized 
view in place of one or more tables specified in the SELECT statement. 
This substitution is called query rewrite . It takes place only if cost 
optimization is enabled and the QUERY_REWRITE_ENABLED parameter 
is set to TRUE. To determine whether query rewrite has occurred, use 

the EXPLAIN PLAN statement. 


For you to select data from a table, materialized view, analytic view, or 
hierarchy, the object must be in your own schema or you must have 

the READ or SELECT privilege on the table, materialized view, analytic 
view, or hierarchy. 


For you to select rows from the base tables of a view: 
The object must be in your own schema or you must have 
the READ or SELECT privilege on it, and 
e Whoever owns the schema containing the object must have 
the READ or SELECT privilege on the base tables. 


The READ ANY TABLE or SELECT ANY TABLE system privilege also 
allows you to select data from any table, materialized view, analytic view, 
or hierarchy, or the base table of any materialized view, analytic view, or 
hierarchy. 


To specify the FOR UPDATE clause, the preceding prerequisites apply with 
the following exception: The READ and READ ANY TABLE privileges, 
where mentioned, do not allow you to specify the FOR UPDATE clause. 


To issue an Oracle Flashback Query using the flashback_query_clause , 
you must have the READ or SELECT privilege on the objects in the select 
list. In addition, either you must have FLASHBACK object privilege on the 
objects in the select list, or you must 

have FLASHBACK ANY TABLE system privilege. 


Examples 
SQL Macros - Table Valued Macros: Examples 


The macro function budget computes the amount of each department's 
budget for a given job. It returns the number of employees in each 
department with the specified job title. 


create or replace function budget(job varchar2) return varchar2 
SQL_MACRO is 
begin 
return q'{ 
select deptno, sum(sal) budget 
from emp 
where job = budget.job 
group by deptno 
F 
end; 
/ 
SELECT * FROM budget (MANAGER); 
DEPTNO BUDGET 


20 2975 
30 2850 
10 2450 


Using a PL/SQL Function in the WITH Clause: Examples 


The following example declares and defines a PL/SQL 

function get_domain in the WITH clause. The get_domain function returns 
the domain name from a URL string, assuming that the URL string has the 
"www" prefix immediately preceding the domain name, and the domain 
name is separated by dots on the left and right. The SELECT statement 
uses get_domain to find distinct catalog domain names from 

the orders table in the oe schema. 


WITH 

FUNCTION get_domain(url VARCHAR2) RETURN VARCHAR2 IS 
pos BINARY_INTEGER; 
len BINARY_INTEGER; 

BEGIN 
pos := INSTR(url, 'www.'); 
len := INSTR(SUBSTR(url, pos + 4), '.') - 1; 
RETURN SUBSTR(url, pos + 4, len); 

END; 

SELECT DISTINCT get_domain(catalog_url) 
FROM product_information; 

/ 


Subquery Factoring: Example 


The following statement creates the query 
names dept_costs and avg_cost for the initial query block containing a join, 
and then uses the query names in the body of the main query. 


WITH 
dept_costs AS ( 
SELECT department_name, SUM(salary) dept_total 
FROM employees e, departments d 
WHERE e.department_id = d.department_id 
GROUP BY department_name), 
avg_cost AS ( 
SELECT SUM(dept_total)/COUNT(*) avg 
FROM dept_costs) 
SELECT * FROM dept_costs 


WHERE dept_total > 
(SELECT avg FROM avg_cost) 
ORDER BY department_name; 


DEPARTMENT NAME DEPT_TOTAL 
Sales 304500 
Shipping 156400 


Recursive Subquery Factoring: Examples 


The following statement shows the employees who directly or indirectly 
report to employee 101 and their reporting level. 


WITH 
reports_to_101 (eid, emp_last, mgr_id, reportLevel) AS 


SELECT employee_id, last_name, manager_id, 0 reportLevel 
FROM employees 
WHERE employee_id = 101 
UNION ALL 
SELECT e.employee_id, e.last_name, e.manager_id, 
reportLevel+1 
FROM reports_to_101 r, employees e 
WHERE reid = e.manager_id 
) 
SELECT eid, emp_last, mgr_id, reportLevel 
FROM reports_to_101 
ORDER BY reportLevel, eid; 


EID EMP_LAST MGR_ID REPORTLEVEL 
101 Kochhar 100 0 

108 Greenberg 101 1 

200 Whalen 101 1 

203 Mavris 101 1 


204 Baer 101 1 


205 Higgins 101 1 


109 Faviet 108 2 
110 Chen 108 2 
111 Sciarra 108 2 
112 Urman 108 2 
113 Popp 108 2 
206 Gietz 205 2 


The following statement shows employees who directly or indirectly report 
to employee 101, their reporting level, and their management chain. 


WITH 
reports_to_101 (eid, emp_last, mgr_id, reportLevel, mgr_list) AS 


SELECT employee_id, last_name, manager_id, 0 reportLevel, 
CAST(manager_id AS VARCHAR2(2000)) 
FROM employees 
WHERE employee_id = 101 
UNION ALL 
SELECT e.employee_id, e.last_name, e.manager_id, 
reportLevel+1, 
CAST(mgr_list || ',' |] manager_id AS VARCHAR2(2000)) 
FROM reports_to_101 r, employees e 
WHERE reid = e.manager_id 


SELECT eid, emp_last, mgr_id, reportLevel, mgr_list 
FROM reports_to_101 
ORDER BY reportLevel, eid; 


EID EMP_LAST MGR_ID REPORTLEVEL 
MGR_LIST 

101 Kochhar 100 0 100 

108 Greenberg 101 1 100,101 

200 Whalen 101 1 100,101 


203 Mavris 101 1 100,101 


204 Baer 101 


205 Higgins 101 
109 Faviet 108 
110 Chen 108 
111 Sciarra 108 
112 Urman 108 
113 Popp 108 
206 Gietz 205 


1 100,101 
1 100,101 
2 100,101,108 
2 100,101,108 
2 100,101,108 
2 100,101,108 
2 100,101,108 
2 100,101,205 


The following statement shows the employees who directly or indirectly 
report to employee 101 and their reporting level. It stops at reporting level 


1. 


WITH 


reports_to_101 (eid, emp_last, mgr_id, reportLevel) AS 


( 


SELECT employee_id, last_name, manager_id, 0 reportLevel 


FROM employees 
WHERE employee_id = 101 
UNION ALL 


SELECT e.employee_id, e.last_name, e.manager_id, reportLevel+1 


FROM reports_to_101 r, employees e 


WHERE r.eid = e.manager_id 
) 


SELECT eid, emp_last, mgr_id, reportLevel 


FROM reports_to_101 
WHERE reportLevel <= 1 
ORDER BY reportLevel, eid; 


EID EMP_LAST MGR_ID REPORTLEVEL 
101 Kochhar 100 0 

108 Greenberg 101 1 

200 Whalen 101 1 

203 Mavris 101 1 


204 Baer 101 


205 Higgins 101 1 


The following statement shows the entire organization, indenting for each 
level of management. 


WITH 
org_chart (eid, emp_last, mgr_id, reportLevel, salary, job_id) AS 
( 
SELECT employee_id, last_name, manager_id, 0 reportLevel, 
salary, job_id 
FROM employees 
WHERE manager_id is null 
UNION ALL 
SELECT e.employee_id, e.last_name, e.manager_id, 
r.reportLevel+1 reportLevel, e.salary, e.job_id 
FROM org_chart r, employees e 
WHERE r.eid = e.manager_id 
) 
SEARCH DEPTH FIRST BY emp_last SET order1 
SELECT lpad(' ',2*reportLevel)||emp_last emp_name, eid, mgr_id, 
salary, job_id 


FROM org_chart 
ORDER BY order1; 
EMP_NAME EID MGR ID SALARY JOB _ID 
King 100 24000 AD_PRES 
Cambrault 148 100 11000 SA MAN 
Bates 172 148 7300 SA_REP 
Bloom 169 148 10000SA_REP 
Fox 170 148 9600 SA_REP 
Kumar 173 148 6100 SA_REP 
Ozer 168 148 11500SA REP 
Smith 171 148 7400 SA_REP 
De Haan 102 100 17000 AD_VP 


Hunold 103 102 9000 IT_PROG 


Austin 105 103 4800 IT_PROG 


Ernst 104 103 6000 IT_PROG 
Lorentz 107 103 4200 IT_PROG 
Pataballa 106 103 4800 IT_PROG 
Errazuriz 147 100 12000 SA MAN 
Ande 166 147 6400 SA REP 


The following statement shows the entire organization, indenting for each 
level of management, with each level ordered by hire_date . The value of 
is_cycle is set to Y for any employee who has the same hire_date as any 
manager above him in the management chain. 


WITH 
dup_hiredate (eid, emp_last, mgr_id, reportLevel, hire_date, job_id) 
AS 


SELECT employee_id, last_name, manager_id, 0 reportLevel, 
hire_date, job_id 
FROM employees 
WHERE manager_id is null 
UNION ALL 
SELECT e.employee_id, e.last_name, e.manager_id, 
r.reportLevel+1 reportLevel, e.hire_date, e.job_id 
FROM dup_hiredate r, employees e 
WHERE reid = e.manager_id 
) 
SEARCH DEPTH FIRST BY hire_date SET order1 
CYCLE hire_date SET is_cycle TO 'Y' DEFAULT 'N' 
SELECT lpad(' ',2*reportLevel)||emp_last emp_name, eid, mgr_id, 
hire_date, job_id, is_cycle 
FROM dup_hiredate 
ORDER BY order1; 


EMP_NAME EID MGR_ID HIRE_DATE JOB_ID 
IS_CYCLE 


17-JUN-03 AD_PRES N 


King 100 
De Haan 102 100 13-JAN-01 AD_VP N 
Hunold 103 102 03-JAN-06 IT_PROG N 
Austin 105 103 25-JUN-05 IT_PROG N 
Kochhar 101 100 21-SEP-05 AD_VP N 
Mavris 203 101 07-JUN-02 HR_REP N 
Baer 204 101 07-JUN-02 PR_REP N 
Higgins 205 101 07-JUN-02 AC_MGR N 
Gietz 206 205 07-JUN-02 AC_ACCOUNT 
Y 
Greenberg 108 101 17-AUG-02 FILMGR N 
Faviet 109 108 16-AUG-02 FI_ACCOUNT N 
Chen 110 108 28-SEP-05 FI ACCOUNT N 


The following statement counts the number of employees under each 


manager. 


WITH 
emp_count (eid, emp_last, mgr_id, mgrLevel, salary, cnt_employees) 


AS 


( 
SELECT employee_id, last_name, manager_id, 0 mgrLevel, salary, 


0 cnt_employees 
FROM employees 


UNION ALL 
SELECT e.employee_id, e.last_name, e.manager_id, 


rmgrLevel+1 mgrLevel, e.salary, 1 cnt_employees 


FROM emp_count r, employees e 
WHERE e.employee_id = r.mgr_id 


) 
SEARCH DEPTH FIRST BY emp_last SET order1 
SELECT emp_last, eid, mgr_id, salary, sum(cnt_employees), 


max(mgrLevel) mgrLevel 


FROM emp_count 

GROUP BY emp_last, eid, mgr_id, salary 
HAVING max(mgrLevel) > 0 

ORDER BY mgr_id NULLS FIRST, emp_last; 


EMP_LAST EID MGR_ID SALARY 
SUM(CNT_EMPLOYEES) MGRLEVEL 


King 100 24000 106 3 
Cambrault 148 100 11000 7 2 
De Haan 102 100 17000 5 2 
Errazuriz 147 100 12000 6 1 
Fripp 121 100 8200 8 1 
Hartstein 201 100 13000 1 1 
Kaufling 122 100 7900 8 1 


Analytic Views: Examples 


The following statement uses the persistent analytic view sales_av. The 
query selects the member_name hierarchical attribute of time_hier, which is 
the alias of a hierarchy of the same name, and values from the sales and 
units measures of the analytic view that are dimensioned by the time 
attribute dimension used by the time_hier hierarchy.. The results of the 
selection are filtered to those for the YEAR level of the hierarchy. The 
results are returned in hierarchical order. 


SELECT time_hier.member_name as TIME, 
sales, 

units 

FROM 

sales_av HIERARCHIE S(time_hier) 
WHERE time_hier.level_name = 'YEAR' 
ORDER BY time_hier.hier_order; 


The results of the query are the following: 


TIME SALES UNITS 

CY2011 6755115980.73 24462444 
CY2012 6901682398.95 24400619 
CY2013 7240938717.57 24407259 
CY2014 7579746352.89 24402666 
CY2015 7941102885.15 24475206 


Transitory Analytic View Examples 


The following statement defines the transitory analytic view my_av in 
the WITH clause. The transitory analytic view is based on the persistent 
analytic view sales_av. The lag_sales calculated measure is 

a LAG calculation that is used at query time. 


WITH 
my_av ANALYTIC VIEW AS ( 
USING sales_av HIERARCHIES (time_hier) 
ADD MEASURES ( 
lag_sales AS (LAG(sales) OVER (HIERARCHY time_hier 
OFFSET 1)) 
) 
) 
SELECT time_hier.member_name time, sales, lag_sales 
FROM my_av HIERARCHIES (time_hier) 
WHERE time_hier.level_ name = 'YEAR' 
ORDER BY time_hier.hier_order; 


The results of the query are the following: 


TIME SALES LAG SALES 
CY2011 6755115981 (null) 

CY2012 6901682399 6755115981 
CY2013 7240938718 6901682399 


CY2014 7579746353 7240938718 
CY2015 7941102885 7579746353 


The following statement defines a transitory analytic view that uses a filter 
clause. 


WITH 
my_av ANALYTIC VIEW AS ( 
USING sales_av HIERARCHIES (time_hier) 
FILTER FACT ( 
time_hier TO quarter_of_year IN (1, 2) 
AND year_name IN (‘CY2011', 'CY2012') 
) 


SELECT time_hier.member_name time, sales 
FROM my_av HIERARCHIES (time_hier) 
WHERE time_hier.level_name IN (‘YEAR’, 'QUARTER’) 
ORDER BY time_hier.hier_order; 


The results of the query are the following: 


TIME SALES 
CY2011 3340459835 
Q1CY2011 1625299627 
Q2CY2011 1715160208 
CY2012 3397271965 
Q1CY2012 1644857783 
Q2CY2012 1752414182 


Inline Analytic View Example 


The following statement defines an inline analytic view in 

the FROM clause. The transitory analytic view is based on the persistent 
analytic view sales_av. The lag_sales calculated measure is 

a LAG calculation that is used at query time. 


SELECT time_hier.member_name time, sales, lag_sales 
FROM 
ANALYTIC VIEW ( 
USING sales_av HIERARCHIES (time_hier) 
ADD MEASURES ( 
lag_sales AS (LAG(sales) OVER (HIERARCHY time_hier 
OFFSET 1)) 
) 
) 
WHERE time_hier.level_ name = 'YEAR' 
ORDER BY time_hier.hier_order; 


The results of the query are the following: 


TIME SALES LAG SALES 
CY2011 6755115981 (null) 

CY2012 6901682399 6755115981 
CY2013 7240938718 6901682399 
CY2014 7579746353 7240938718 
CY2015 7941102885 7579746353 


Simple Query Examples 


The following statement selects rows from the employees table with the 
department number of 30: 


SELECT * 
FROM employees 
WHERE department_id = 30 
ORDER BY last_name; 


The following statement selects the name, job, salary and department 


number of all employees except purchasing clerks from department number 
30: 


SELECT last_name, job_id, salary, department_id 
FROM employees 
WHERE NOT (job_id = 'PU_CLERK' AND department_id = 30) 
ORDER BY last_name; 


The following statement selects from subqueries in the FROM clause and 
for each department returns the total employees and salaries as a decimal 
value of all the departments: 


SELECT a.department_id "Department", 
a.num_emp/b.total_count "%_Employees", 
a.sal_sum/b.total_sal "%_Salary" 

FROM 

(SELECT department_id, COUNT(*) num_emp, SUM(salary) 

sal_sum 
FROM employees 
GROUP BY department_id) a, 

(SELECT COUNT(*) total_count, SUM(salary) total_sal 
FROM employees) b 

ORDER BY a.department_id; 


Selecting from a Partition: Example 


You can select rows from a single partition of a partitioned table by 
specifying the keyword PARTITION in the FROM clause. This SQL 
statement assigns an alias for and retrieves rows from 

the sales_q2_2000 partition of the sample table sh.sales: 


SELECT * FROM sales PARTITION (sales_q2_ 2000) s 
WHERE s.amount_sold > 1500 
ORDER BY cust_id, time_id, channel_id; 


The following example selects rows from the oe.orders table for orders 
earlier than a specified date: 


SELECT * FROM orders 
WHERE order_date < TO_DATE('2006-06-15', "YY Y Y-MM-DD'); 


Selecting a Sample: Examples 


The following query estimates the number of orders in the oe.orders table: 


SELECT COUNT(*) * 10 FROM orders SAMPLE (10); 


COUNT(*)*10 


Because the query returns an estimate, the actual return value may differ 
from one query to the next. 


SELECT COUNT(*) * 10 FROM orders SAMPLE (10); 


COUNT(*)*10 


The following query adds a seed value to the preceding query. Oracle 
Database always returns the same estimate given the same seed value: 


SELECT COUNT(*) * 10 FROM orders SAMPLE(10) SEED (1); 
COUNT(*)*10 
SELECT COUNT(*) * 10 FROM orders SAMPLE(10) SEED(4); 


COUNT(*)*10 


120 
SELECT COUNT(*) * 10 FROM orders SAMPLE(10) SEED (1); 


COUNT(*)*10 


Using Flashback Queries: Example 


The following statements show a current value from the sample 

table hr.employees and then change the value. The intervals used in these 
examples are very short for demonstration purposes. Time intervals in your 
own environment are likely to be larger. 


SELECT salary FROM employees 
WHERE last_name = 'Chung'; 


SALARY 


UPDATE employees SET salary = 4000 
WHERE last_name = 'Chung'; 
1 row updated. 


SELECT salary FROM employees 
WHERE last_name = 'Chung'; 


SALARY 


To learn what the value was before the update, you can use the following 
Flashback Query: 


SELECT salary FROM employees 

AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' 
MINUTE) 

WHERE last_name = 'Chung'; 


SALARY 


To learn what the values were during a particular time period, you can use a 
version Flashback Query: 


SELECT salary FROM employees 
VERSIONS BETWEEN TIMESTAMP 
SYSTIMESTAMP - INTERVAL '10' MINUTE AND 
SYSTIMESTAMP - INTERVAL '1' MINUTE 
WHERE last_name = 'Chung'; 


To revert to the earlier value, use the Flashback Query as the subquery of 
another UPDATE statement: 


UPDATE employees SET salary = 

(SELECT salary FROM employees 

AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '2' 
MINUTE) 

WHERE last_name = 'Chung’) 

WHERE last_name = 'Chung'; 
1 row updated. 


SELECT salary FROM employees 
WHERE last_name = 'Chung'; 


SALARY 


Using the GROUP BY Clause: Examples 


To return the minimum and maximum salaries for each department in 
the employees table, issue the following statement: 


SELECT department_id, MIN(salary), MAX (salary) 
FROM employees 
GROUP BY department_id 
ORDER BY department_id; 


To return the minimum and maximum salaries for the clerks in each 
department, issue the following statement: 


SELECT department_id, MIN(salary), MAX (salary) 
FROM employees 
WHERE job_id = 'PU_CLERK' 
GROUP BY department_id 
ORDER BY department_id; 


Using the GROUP BY CUBE Clause: Example 


To return the number of employees and their average yearly salary across 
all possible combinations of department and job category, issue the 
following query on the sample tables hr.employees and hr.departments: 


SELECT DECODE(GROUPING(department_name), 1, 'All 
Departments’, 
department_name) AS department_name, 
DECODE(GROUPING(job_id), 1, ‘All Jobs’, job_id) AS job_id, 
COUNT(*) "Total Empl", AVG(salary) * 12 "Average Sal" 
FROM employees e, departments d 
WHERE d.department_id = e.department_id 
GROUP BY CUBE (department_name, job_id) 
ORDER BY department_name, job_id; 


DEPARTMENT_NAME JOB_ID Total Empl Average Sal 


Accounting AC_ACCOUNT 1 99600 


Accounting AC_MGR 1 144000 
Accounting All Jobs 2 121800 
Administration AD ASST 1 52800 
Shipping ST_CLERK 20 33420 
Shipping ST_MAN 5 87360 


Using the GROUPING SETS Clause: Example 


The following example finds the sum of sales aggregated for three precisely 
specified groups: 


- (channel_desc, calendar_month_desc, country_id) 
(channel_desc, country_id) 
(calendar_month_desc, country_id) 


Without the GROUPING SETS syntax, you would have to write less 
efficient queries with more complicated SQL. For example, you could run 
three separate queries and UNION them, or run a query with 

a CUBE(channel_desc, calendar_month_desc, country_id) operation and 
filter out five of the eight groups it would generate. 


SELECT channel_desc, calendar_month_desc, co.country_id, 
TO_CHAR(sum(amount_sold) , '9,999,999,999') SALES$ 
FROM sales, customers, times, channels, countries co 
WHERE sales.time_id=times.time_id 
AND sales.cust_id=customers.cust_id 
AND sales.channel_id= channels.channel_id 
AND customers.country_id = co.country_id 
AND channels.channel_desc IN (‘Direct Sales’, 'Internet’) 
AND times.calendar_month_desc IN ('2000-09", '2000-10') 
AND co.country_iso_code IN (‘UK’, 'US') 
GROUP BY GROUPING SETS( 
(channel_desc, calendar_month_desc, co.country_id), 
(channel_desc, co.country_id), 
(calendar_month_desc, co.country_id) ); 


CHANNEL _DESC CALENDAR COUNTRY_ID SALES$ 


Internet 2000-09 52790 124,224 
Direct Sales 2000-09 52790 638,201 
Internet 2000-10 52790 137,054 


Direct Sales 2000-10 52790 682,297 
2000-09 52790 762,425 
2000-10 52790 819,351 

Internet 52790 261,278 

Direct Sales 52790 1,320,497 


Hierarchical Query Examples 


The following query with a CONNECT BY clause defines a hierarchical 
relationship in which the employee_id value of the parent row is equal to 
the manager_id value of the child row: 


SELECT last_name, employee_id, manager_id FROM employees 
CONNECT BY employee_id = manager_id 
ORDER BY last_name; 


In the following CONNECT BY clause, the PRIOR operator applies only to 
the employee_id value. To evaluate this condition, the database 

evaluates employee_id values for the parent row and manager_id, salary, 
and commission_pct values for the child row: 


SELECT last_name, employee_id, manager_id FROM employees 
CONNECT BY PRIOR employee_id = manager_id 
AND salary > commission_pct 
ORDER BY last_name; 


To qualify as a child row, a row must have a manager_id value equal to 
the employee_id value of the parent row and it must have a salary value 
greater than its commission_pct value. 


Using the HAVING Condition: Example 


To return the minimum and maximum salaries for the employees in each 
department whose lowest salary is less than $5,000, issue the next 
statement: 


SELECT department_id, MIN(salary), MAX (salary) 
FROM employees 
GROUP BY department_id 
HAVING MIN(salary) < 5000 
ORDER BY department_id; 


DEPARTMENT_ID MIN(SALARY) MAX(SALARY) 
10 4400 4400 
30 2500 11000 
50 2100 8200 
60 4200 9000 


The following example uses a correlated subquery in a HAVING clause that 
eliminates from the result set any departments without managers and 
managers without departments: 


SELECT department_id, manager_id 
FROM employees 
GROUP BY department_id, manager_id HAVING (department_id, 
manager_id) IN 
(SELECT department_id, manager_id FROM employees x 
WHERE x.department_id = employees.department_id) 
ORDER BY department_id; 


Using the ORDER BY Clause: Examples 


To select all purchasing clerk records from employees and order the results 
by salary in descending order, issue the following statement: 


SELECT * 
FROM employees 


WHERE job_id = 'PU_CLERK' 
ORDER BY salary DESC; 


To select information from employees ordered first by ascending 
department number and then by descending salary, issue the following 
statement: 


SELECT last_name, department_id, salary 
FROM employees 
ORDER BY department_id ASC, salary DESC, last_name; 


To select the same information as the previous SELECT and use the 
positional ORDER BY notation, issue the following statement, which 
orders by ascending department_id, then descending salary, and finally 
alphabetically by last_name: 


SELECT last_name, department_id, salary 
FROM employees 
ORDER BY 2 ASC, 3 DESC, 1; 


The MODEL clause: Examples 


The view created below is based on the sample sh schema and is used by 
the example that follows. 


CREATE OR REPLACE VIEW sales_view_ref AS 
SELECT country_name country, 
prod_name prod, 
calendar_year year, 
SUM(amount_sold) sale, 
COUNT(amount_sold) cnt 
FROM sales,times,customers,countries, products 
WHERE sales.time_id = times.time_id 
AND sales.prod_id = products.prod_id 
AND sales.cust_id = customers.cust_id 
AND customers.country_id = countries.country_id 


AND ( customers.country_id = 52779 
OR customers.country_id = 52776 ) 
AND ( prod_name = 'Standard Mouse' 
OR prod_name = 'Mouse Pad' ) 
GROUP BY country_name,prod_name,calendar_year; 


SELECT country, prod, year, sale 
FROM sales_view_ref 
ORDER BY country, prod, year; 


COUNTRY PROD YEAR SALE 
France Mouse Pad 1998 2509.42 
France Mouse Pad 1999 3678.69 
France Mouse Pad 2000 3000.72 
France Mouse Pad 2001 3269.09 
France Standard Mouse 1998 2390.83 
France Standard Mouse 1999 2280.45 
France Standard Mouse 2000 1274.31 
France Standard Mouse 2001 2164.54 
Germany Mouse Pad 1998 5827.87 
Germany Mouse Pad 1999 8346.44 
Germany Mouse Pad 2000 7375.46 
Germany Mouse Pad 2001 9535.08 
Germany Standard Mouse 1998 7116.11 
Germany Standard Mouse 1999 6263.14 
Germany Standard Mouse 2000 2637.31 
Germany Standard Mouse 2001 6456.13 


16 rows selected. 


The next example creates a multidimensional array 
from sales_view_ref with columns containing country, product, year, and 
sales. It also: 


- Assigns the sum of the sales of the Mouse Pad for years 1999 and 
2000 to the sales of the Mouse Pad for year 2001, if a row containing 


sales of the Mouse Pad for year 2001 exists. 


- Assigns the value of sales of the Standard Mouse for year 2001 to 
sales of the Standard Mouse for year 2002, creating a new row if a 
row containing sales of the Standard Mouse for year 2002 does not 
exist. 


SELECT country,prod,year,s 

FROM sales_view_ref 

MODEL 
PARTITION BY (country) 
DIMENSION BY (prod, year) 
MEASURES (sale s) 
IGNORE NAV 
UNIQUE DIMENSION 
RULES UPSERT SEQUENTIAL ORDER 


s[prod="Mouse Pad', year=2001] = 
s['Mouse Pad’, 1999] + s['Mouse Pad’, 2000], 
s['Standard Mouse’, 2002] = s['Standard Mouse’, 2001] 


) 
ORDER BY country, prod, year; 


COUNTRY PROD YEAR SALE 
France Mouse Pad 1998 2509.42 
France Mouse Pad 1999 3678.69 
France Mouse Pad 2000 3000.72 
France Mouse Pad 2001 6679.41 
France Standard Mouse 1998 2390.83 
France Standard Mouse 1999 2280.45 
France Standard Mouse 2000 1274.31 
France Standard Mouse 2001 2164.54 
France Standard Mouse 2002 2164.54 
Germany Mouse Pad 1998 5827.87 
Germany Mouse Pad 1999 8346.44 
Germany Mouse Pad 2000 7375.46 


Germany Mouse Pad 2001 15721.9 


Germany Standard Mouse 1998 7116.11 


Germany Standard Mouse 1999 6263.14 
Germany Standard Mouse 2000 2637.31 
Germany Standard Mouse 2001 6456.13 
Germany Standard Mouse 2002 6456.13 


18 rows selected. 


The first rule uses UPDATE behavior because symbolic referencing is used 
on the left-hand side of the rule. The rows represented by the left-hand side 
of the rule exist, so the measure columns are updated. If the rows did not 
exist, then no action would have been taken. 


The second rule uses UPSERT behavior because positional referencing is 
used on the left-hand side and a single cell is referenced. The rows do not 
exist, SO new rows are inserted and the related measure columns are 
updated. If the rows did exist, then the measure columns would have been 
updated. 


The next example uses the same sales_view_ref view and the analytic 
function SUM to calculate a cumulative sum (csum) of sales per country 
and per year. 


SELECT country, year, sale, csum 
FROM 
(SELECT country, year, SUM(sale) sale 
FROM sales_view_ref 
GROUP BY country, year 
) 
MODEL DIMENSION BY (country, year) 
MEASURES (sale, 0 csum) 
RULES (csum[any, any]= 
SUM(sale) OVER (PARTITION BY country 
ORDER BY year 
ROWS UNBOUNDED PRECEDING) 


ORDER BY country, year; 


COUNTRY YEAR SALE CSUM 


France 1998 4900.25 4900.25 
France 1999 5959.14 10859.39 
France 2000 4275.03 15134.42 
France 2001 5433.63 20568.05 
Germany 1998 12943.98 12943.98 
Germany 1999 14609.58 27553.56 
Germany 2000 10012.77 37566.33 
Germany 2001 15991.21 53557.54 


8 rows selected. 


Row Limiting: Examples 


The following statement returns the 5 employees with the 
lowest employee_id values: 


SELECT employee_id, last_name 
FROM employees 
ORDER BY employee_id 
FETCH FIRST 5 ROWS ONLY; 


EMPLOYEE _ID LAST NAME 
100 King 
101 Kochhar 
102 De Haan 
103 Hunold 
104 Ernst 


The following statement returns the next 5 employees with the 
lowest employee_id values: 


SELECT employee_id, last_name 
FROM employees 


ORDER BY employee_id 
OFFSET 5 ROWS FETCH NEXT 5 ROWS ONLY; 


EMPLOYEE _ ID LAST NAME 
105 Austin 
106 Pataballa 
107 Lorentz 
108 Greenberg 
109 Faviet 


The following statement returns the 5 percent of employees with the lowest 
salaries: 


SELECT employee_id, last_name, salary 


FROM employees 
ORDER BY salary 
FETCH FIRST 5 PERCENT ROWS ONLY; 
EMPLOYEE ID LAST NAME SALARY 
132 Olson 2100 
128 Markle 2200 
136 Philtanker 2200 
127 Landry 2400 
135 Gee 2400 
119 Colmenares 2500 


Because WITH TIES is specified, the following statement returns the 5 
percent of employees with the lowest salaries, plus all additional employees 
with the same salary as the last row fetched in the previous example: 


SELECT employee_id, last_name, salary 
FROM employees 
ORDER BY salary 
FETCH FIRST 5 PERCENT ROWS WITH TIES; 


EMPLOYEE_ID LAST_NAME SALARY 


132 Olson 2100 
128 Markle 2200 
136 Philtanker 2200 
127 Landry 2400 
135 Gee 2400 
119 Colmenares 2500 
131 Marlow 2500 
140 Patel 2500 
144 Vargas 2500 
182 Sullivan 2500 
191 Perkins 2500 


Using the FOR UPDATE Clause: Examples 


The following statement locks rows in the employees table with purchasing 
clerks located in Oxford, which has location_id 2500, and locks rows in 
the departments table with departments in Oxford that have purchasing 
clerks: 


SELECT e.employee_id, e.salary, e.commission_pct 
FROM employees e, departments d 
WHERE job_id = 'SA_REP' 
AND e.department_id = d.department_id 
AND location_id = 2500 
ORDER BY e.employee_id 
FOR UPDATE; 


The following statement locks only those rows in the employees table with 
purchasing clerks located in Oxford. No rows are locked in 
the departments table: 


SELECT e.employee_id, e.salary, e.commission_pct 
FROM employees e JOIN departments d 


USING (department_id) 
WHERE job_id = 'SA_REP' 
AND location_id = 2500 
ORDER BY e.employee_id 
FOR UPDATE OF e.salary; 


Using the WITH CHECK OPTION Clause: Example 


The following statement is legal even though the third value inserted 
violates the condition of the subquery where_clause : 


INSERT INTO (SELECT department_id, department_name, 
location_id 
FROM departments WHERE location_id < 2000) 
VALUES (9999, 'Entertainment', 2500); 


However, the following statement is illegal because it contains 
the WITH CHECK OPTION clause: 


INSERT INTO (SELECT department_id, department_name, 
location_id 
FROM departments WHERE location_id < 2000 WITH CHECK 
OPTION) 
VALUES (9999, 'Entertainment', 2500); 
kK 


ERROR at line 2: 
ORA-01402: view WITH CHECK OPTION where-clause violation 


Using PIVOT and UNPIVOT: Examples 


The oe.orders table contains information about when an order was placed 
(order_date), how it was place (order_mode), and the total amount of the 
order (order_total), as well as other information. The following example 
shows how to use the PIVOT clause to pivot order_mode values into 
columns, aggregating order_total data in the process, to get yearly totals by 
order mode: 


CREATE TABLE pivot_table AS 

SELECT * FROM 

(SELECT EXTRACT(YEAR FROM order_date) year, order_mode, 
order_total FROM orders) 

PIVOT 

(SUM(order_total) FOR order_mode IN (‘direct' AS Store, ‘online’ AS 
Internet)); 


SELECT * FROM pivot_table ORDER BY year; 


YEAR STORE INTERNET 
2004 5546.6 

2006 371895.5 100056.6 
2007 1274078.8 1271019.5 
2008 252108.3 393349.4 


The UNPIVOT clause lets you rotate specified columns so that the input 
column headings are output as values of one or more descriptor columns, 
and the input column values are output as values of one or more measures 
columns. The first query that follows shows that nulls are excluded by 
default. The second query shows that you can include nulls using 

the INCLUDE NULLS clause. 


SELECT * FROM pivot_table 
UNPIVOT (yearly_total FOR order_mode IN (store AS ‘direct’, 
internet AS 'online')) 
ORDER BY year, order_mode; 


YEAR ORDER_ YEARLY TOTAL 
2004 direct 5546.6 

2006 direct 371895.5 

2006 online 100056.6 

2007 direct 1274078.8 

2007 online 1271019.5 


2008 direct 252108.3 
2008 online 393349.4 


7 rows selected. 


SELECT * FROM pivot_table 
UNPIVOT INCLUDE NULLS 
(yearly_total FOR order_mode IN (store AS ‘direct’, internet AS 
‘online’)) 
ORDER BY year, order_mode; 


YEAR ORDER_ YEARLY TOTAL 
2004 direct 5546.6 

2004 online 

2006 direct 371895.5 

2006 online 100056.6 

2007 direct 1274078.8 

2007 online 1271019.5 

2008 direct 252108.3 

2008 online 393349.4 


8 rows selected. 


Using Join Queries: Examples 


The following examples show various ways of joining tables in a query. In 
the first example, an equijoin returns the name and job of each employee 
and the number and name of the department in which the employee works: 


SELECT last_name, job_id, departments.department_id, 
department_name 
FROM employees, departments 
WHERE employees.department_id = departments.department_id 
ORDER BY last_name, job_id; 


LAST_NAME JOB_ID DEPARTMENT _ID 
DEPARTMENT_NAME 


Abel SA_REP 80 Sales 

Ande SA_REP 80 Sales 
Atkinson ST_CLERK 50 Shipping 
Austin IT_PROG 60 IT 


You must use a join to return this data because employee names and jobs 
are stored in a different table than department names. Oracle Database 
combines rows of the two tables according to this join condition: 


employees.department_id = departments.department_id 


The following equijoin returns the name, job, department number, and 
department name of all sales managers: 


SELECT last_name, job_id, departments.department_id, 
department_name 
FROM employees, departments 
WHERE employees.department_id = departments.department_id 
AND job_id ='SA_MAN' 
ORDER BY last_name; 


LAST NAME JOB_ID DEPARTMENT ID 
DEPARTMENT NAME 

Cambrault SA_MAN 80 Sales 
Errazuriz SA_MAN 80 Sales 
Partners SA MAN 80 Sales 

Russell SA MAN 80 Sales 


Zlotkey SA_MAN 80 Sales 


This query is identical to the preceding example, except that it uses an 
additional where_clause condition to return only rows with a job value of 
'SA_MAN'. 


Using Subqueries: Examples 


To determine who works in the same department as employee ‘Lorentz’, 
issue the following statement: 


SELECT last_name, department_id FROM employees 
WHERE department_id = 
(SELECT department_id FROM employees 
WHERE last_name = 'Lorentz') 
ORDER BY last_name, department_id; 


To give all employees in the employees table a 10% raise if they have 
changed jobs—if they appear in the job_history table—issue the following 
statement: 


UPDATE employees 

SET salary = salary * 1.1 

WHERE employee_id IN (SELECT employee_id FROM 
job_history); 


To create a second version of the departments table new_departments, with 
only three of the columns of the original table, issue the following 
statement: 


CREATE TABLE new_departments 
(department_id, department_name, location_id) 
AS SELECT department_id, department_name, location_id 
FROM departments; 


Using Self Joins: Example 


The following query uses a self join to return the name of each employee 
along with the name of the employee's manager. A WHERE clause is added 


to shorten the output. 


SELECT e1.last_namel||' works for '||e2.last_name 
"Employees and Their Managers" 
FROM employees e1, employees e2 
WHERE e1.manager_id = e2.employee_id 
AND el1.last_name LIKE 'R%' 
ORDER BY e1.last_name; 


Employees and Their Managers 
Rajs works for Mourgos 
Raphaely works for King 
Rogers works for Kaufling 
Russell works for King 


The join condition for this query uses the aliases e1 and e2 for the sample 
table employees: 


e1.manager_id = e2.employee_id 


Using Outer Joins: Examples 


The following example shows how a partitioned outer join fills data gaps in 
rows to facilitate analytic function specification and reliable report 
formatting. The example first creates a small data table to be used in the 
join: 


SELECT d.department_id, e.last_name 
FROM departments d LEFT OUTER JOIN employees e 
ON d.department_id = e.department_id 
ORDER BY d.department_id, e.last_name; 


Users familiar with the traditional Oracle Database outer joins syntax will 
recognize the same query in this form: 


SELECT d.department_id, e.last_name 
FROM departments d, employees e 
WHERE d.department_id = e.department_id(+) 
ORDER BY d.department_id, e.last_name; 


Oracle strongly recommends that you use the more flexible FROM clause 
join syntax shown in the former example. 


The left outer join returns all departments, including those without any 
employees. The same statement with a right outer join returns all 
employees, including those not yet assigned to a department: 


SELECT d.department_id, e.last_name 
FROM departments d RIGHT OUTER JOIN employees e 
ON d.department_id = e.department_id 
ORDER BY d.department_id, e.last_name; 


DEPARTMENT_ID LAST_NAME 


110 Gietz 

110 Higgins 
Grant 
Zeuss 


It is not clear from this result whether employees Grant and Zeuss 
have department_id NULL, or whether their department_id is not in 
the departments table. To determine this requires a full outer join: 


SELECT d.department_id as d_dept_id, e.department_id as e_dept_id, 
e.last_name 
FROM departments d FULL OUTER JOIN employees e 
ON d.department_id = e.department_id 
ORDER BY d.department_id, e.last_name; 


D_DEPT_ID E_DEPT_ID LAST_NAME 


110 110 Gietz 
110 110 Higgins 


999 Zeuss 
Grant 


Because the column names in this example are the same in both tables in 
the join, you can also use the common column feature by specifying 

the USING clause of the join syntax. The output is the same as for the 
preceding example except that the USING clause coalesces the two 
matching columns department_id into a single column output: 


SELECT department_id AS d_e_dept_id, e.last_name 
FROM departments d FULL OUTER JOIN employees e 
USING (department_id) 

ORDER BY department_id, e.last_name; 


D_E_DEPT_ID LAST_NAME 


110 Higgins 
110 Gietz 


260 

270 

999 Zeuss 
Grant 


Using Partitioned Outer Joins: Examples 


The following example shows how a partitioned outer join fills in gaps in 
rows to facilitate analytic calculation specification and reliable report 


formatting. The example first creates and populates a simple table to be 
used in the join: 


CREATE TABLE inventory (time_id DATE, 
product VARCHAR2(10), 
quantity NUMBER); 


INSERT INTO inventory VALUES (TO_DATE('01/04/01', 
'DD/MM/YY’), ‘bottle’, 10); 

INSERT INTO inventory VALUES (TO_DATE('06/04/01', 
'DD/MM/YY’), ‘bottle’, 10); 

INSERT INTO inventory VALUES (TO_DATE('01/04/01', 
'DD/MM/YY’), 'can', 10); 

INSERT INTO inventory VALUES (TO_DATE('04/04/01', 
'DD/MM/YY’), 'can', 10); 


SELECT times.time_id, product, quantity FROM inventory 

PARTITION BY (product) 

RIGHT OUTER JOIN times ON (times.time_id = 
inventory.time_id) 

WHERE times.time_id BETWEEN TO_DATE(‘01/04/01', 
'DD/MM/YY') 

AND TO_DATE('06/04/01', 'DD/MM/YY') 
ORDER BY 2,1; 


TIME ID PRODUCT QUANTITY 
01-APR-O01 bottle 10 
02-APR-01 bottle 
03-APR-01 bottle 
04-APR-01 bottle 
05-APR-01 bottle 
06-APR-01 bottle 10 
01-APR-01 can 10 
02-APR-01 can 

03-APR-01 can 

04-APR-01 can 10 


05-APR-01 can 
06-APR-01 can 


12 rows selected. 


The data is now more dense along the time dimension for each partition of 
the product dimension. However, each of the newly added rows within each 
partition is null in the quantity column. It is more useful to see the nulls 
replaced by the preceding non-NULL value in time order. You can achieve 
this by applying the analytic function LAST_VALUE on top of the query 
result: 


SELECT time_id, product, LAST_VALUE(quantity IGNORE 
NULLS) 
OVER (PARTITION BY product ORDER BY time_id) quantity 
FROM ( SELECT times.time_id, product, quantity 
FROM inventory PARTITION BY (product) 
RIGHT OUTER JOIN times ON (times.time_id = 
inventory.time_id) 
WHERE times.time_id BETWEEN TO_DATE(‘01/04/01', 
'DD/MM/YY') 
AND TO_DATE(‘06/04/01', 'DD/MM/YY')) 
ORDER BY 2,1; 


TIME ID PRODUCT QUANTITY 


01-APR-01 bottle 10 
02-APR-01 bottle 10 
03-APR-01 bottle 10 
04-APR-01 bottle 10 
05-APR-01 bottle 10 
06-APR-01 bottle 10 
01-APR-01 can 10 
02-APR-01 can 10 
03-APR-01 can 10 


04-APR-01 can 10 


05-APR-01 can 10 
06-APR-01 can 10 


12 rows selected. 


Using Antijoins: Example 


The following example selects a list of employees who are not in a 
particular set of departments: 


SELECT * FROM employees 
WHERE department_id NOT IN 
(SELECT department_id FROM departments 
WHERE location_id = 1700) 
ORDER BY last_name; 


Using Semijoins: Example 


In the following example, only one row needs to be returned from 

the departments table, even though many rows in the employees table might 
match the subquery. If no index has been defined on the salary column 

in employees, then a semijoin can be used to improve query performance. 


SELECT * FROM departments 
WHERE EXISTS 
(SELECT * FROM employees 
WHERE departments.department_id = employees.department_id 
AND employees.salary > 2500) 
ORDER BY department_name; 


Using CROSS APPLY and OUTER APPLY Joins: Examples 


The following statement uses the CROSS APPLY clause of the 
cross_outer_apply_clause . The join returns only rows from the table on the 
left side of the join (departments) that produce a result from the inline view 
on the right side of the join. That is, the join returns only the departments 
that have at least one employee. The WHERE clause restricts the result set 


to include only the Marketing, Operations, and Public Relations 
departments. However, the Operations department is not included in the 
result set because it has no employees. 


SELECT d.department_name, v.employee_id, v.last_name 
FROM departments d CROSS APPLY (SELECT * FROM 
employees e 
WHERE e.department_id = d.department_id) v 
WHERE d.department_name IN ('Marketing', 'Operations', 'Public 
Relations’) 
ORDER BY d.department_name, v.employee_id; 


DEPARTMENT_NAME EMPLOYEE_ID LAST_NAME 
Marketing 201 Hartstein 

Marketing 202 Fay 

Public Relations 204 Baer 


The following statement uses the OUTER APPLY clause of the 
cross_outer_apply_clause . The join returns all rows from the table on the 
left side of the join (departments) regardless of whether they produce a 
result from the inline view on the right side of the join. That is, the join 
returns all departments regardless of whether the departments have any 
employees. The WHERE clause restricts the result set to include only the 
Marketing, Operations, and Public Relations departments. The Operations 
department is included in the result set even though it has no employees. 


SELECT d.department_name, v.employee_id, v.last_name 
FROM departments d OUTER APPLY (SELECT * FROM 
employees e 
WHERE e.department_id = d.department_id) v 
WHERE d.department_name IN ('Marketing', 'Operations', 'Public 
Relations’) 
ORDER by d.department_name, v.employee_id; 


DEPARTMENT_NAME EMPLOYEE _ID LAST_NAME 


Marketing 201 Hartstein 


Marketing 202 Fay 
Operations 
Public Relations 204 Baer 


Using Lateral Inline Views: Example 


The following example shows a join with two operands. The second 
operand is an inline view that specifies the first operand, table e, in 
the WHERE clause. This results in an error. 


SELECT * FROM employees e, (SELECT * FROM departments d 
WHERE e.department_id = d.department_id); 
ORA-00904: "E"."DEPARTMENT_ID": invalid identifier 


The following example shows a join with two operands. The second 
operand is a lateral inline view that specifies the first operand, table e, in 
the WHERE clause and succeeds without an error. 


SELECT * FROM employees e, LATERAL(SELECT * FROM 
departments d 
WHERE e.department_id = d.department_id); 


Table Collections: Examples 


You can perform DML operations on nested tables only if they are defined 
as columns of a table. Therefore, when the query_table_expr_clause of 

an INSERT, DELETE, or UPDATE statement is a 
table_collection_expression , the collection expression must be a subquery 
that uses the TABLE collection expression to select the nested table column 
of the table. The examples that follow are based on the following scenario: 


Suppose the database contains a table hr_info with 

columns department_id, location_id, and manager_id, and a column of 
nested table type people which has last_name, department_id, 

and salary columns for all the employees of each respective manager: 


CREATE TYPE people_typ AS OBJECT ( 
last name VARCHAR2(25), 
department _id NUMBER(4), 
salary NUMBER(8,2)); 
/ 
CREATE TYPE people_tab_typ AS TABLE OF people_typ; 
/ 
CREATE TABLE hr_info ( 
department_id NUMBER(4), 
location_Lid NUMBER(4), 
manager id NUMBER(6), 
people people_tab_typ) 
NESTED TABLE people STORE AS people_stor_tab; 


INSERT INTO hr_info VALUES (280, 1800, 999, people_tab_typ0); 


The following example inserts into the people nested table column of 
the hr_info table for department 280: 


INSERT INTO TABLE(SELECT h.people FROM hr_info h 
WHERE h.department_id = 280) 
VALUES ('Smith', 280, 1750); 


The next example updates the department 280 people nested table: 


UPDATE TABLE(SELECT h.people FROM hr_info h 
WHERE h.department_id = 280) p 
SET p.salary = p.salary + 100; 


The next example deletes from the department 280 people nested table: 


DELETE TABLE(SELECT h.people FROM hr_info h 
WHERE h.department_id = 280) p 
WHERE p.salary > 1700; 


Collection Unnesting: Examples 


To select data from a nested table column, use the TABLE collection 
expression to treat the nested table as columns of a table. This process is 
called collection unnesting . 


You could get all the rows from hr_info, which was created in the preceding 
example, and all the rows from the people nested table column 
of hr_info using the following statement: 


SELECT t1.department_id, t2.* FROM hr_info t1, TABLE(t1.people) 
t2 
WHERE t2.department_id = t1.department_id; 


Now suppose that people is not a nested table column of hr_info, but is 
instead a separate table with 

columns last_name, department_id, address, hiredate, and salary. You can 
extract the same rows as in the preceding example with this statement: 


SELECT t1.department_id, t2.* 
FROM hr_info t1, TABLE(CAST(MULTISET( 
SELECT t3.last_name, t3.department_id, t3.salary 
FROM people t3 
WHERE t3.department_id = t1.department_id) 
AS people_tab_typ)) t2; 


Finally, suppose that people is neither a nested table column of 

table hr_info nor a table itself. Instead, you have created a 

function people_func that extracts from various sources the name, 
department, and salary of all employees. You can get the same information 
as in the preceding examples with the following query: 


SELECT t1.department_id, t2.* FROM hr_info t1, TABLE(CAST 
(people_func( ... ) AS people_tab_typ)) t2; 


Using the LEVEL Pseudocolumn: Examples 


The following statement returns all employees in hierarchical order. The 
root row is defined to be the employee whose job is AD_VP. The child rows 
of a parent row are defined to be those who have the employee number of 
the parent row as their manager number. 


SELECT LPAD(' ',2*(LEVEL-1)) || last_name org_chart, 
employee_id, manager_id, job_id 
FROM employees 
START WITH job_id = 'AD_VP' 
CONNECT BY PRIOR employee_id = manager_id; 


ORG_CHART EMPLOYEE _ ID MANAGER ID JOB_ID 


Kochhar 101 100 AD_VP 
Greenberg 108 101 FILMGR 
Faviet 109 108 FIL ACCOUNT 
Chen 110 108 FIL ACCOUNT 
Sciarra 111 108 FI. ACCOUNT 
Urman 112 108 FIL ACCOUNT 
Popp 113 108 FL ACCOUNT 
Whalen 200 101 AD_ASST 
Mavris 203 101 HR_REP 
Baer 204 101 PR_REP 
Higgins 205 101 AC_MGR 
Gietz 206 205 AC_ACCOUNT 
De Haan 102 100 AD_VP 
Hunold 103 102 IT_PROG 
Ernst 104 103 IT_PROG 
Austin 105 103 IT_PROG 
Pataballa 106 103 IT_PROG 
Lorentz 107 103 IT_PROG 


The following statement is similar to the previous one, except that it does 
not select employees with the job FILMGR. 


SELECT LPAD(' ',2*(LEVEL-1)) || last_name org_chart, 


employee_id, manager_id, job_id 
FROM employees 
WHERE job_id != 'FI_LMGR' 
START WITH job_id = 'AD_VP' 
CONNECT BY PRIOR employee_id = manager_id; 


ORG_CHART EMPLOYEE _ ID MANAGER ID JOB_ID 


Kochhar 101 100 AD_VP 
Faviet 109 108 FIL ACCOUNT 
Chen 110 108 FI ACCOUNT 
Sciarra 111 108 FI ACCOUNT 
Urman 112 108 FI ACCOUNT 
Popp 113 108 FI ACCOUNT 
Whalen 200 101 AD_ASST 
Mavris 203 101 HR_REP 
Baer 204 101 PR_REP 
Higgins 205 101 AC MGR 
Gietz 206 205 AC_ACCOUNT 
De Haan 102 100 AD_VP 
Hunold 103 102 IT_ PROG 
Ernst 104 103 IT_PROG 
Austin 105 103 IT_PROG 
Pataballa 106 103 IT_PROG 
Lorentz 107 103 IT_PROG 


Oracle Database does not return the manager Greenberg, although it does 
return employees who are managed by Greenberg. 


The following statement is similar to the first one, except that it uses 


the LEVEL pseudocolumn to select only the first two levels of the 
management hierarchy: 


SELECT LPAD(' ',2*(LEVEL-1)) || last_name org_chart, 
employee_id, manager_id, job_id 
FROM employees 


START WITH job_id = 'AD_PRES' 


CONNECT BY PRIOR employee_id = manager_id AND LEVEL 
<= 2; 


ORG_CHART EMPLOYEE _ ID MANAGER ID JOB_ID 


King 100 AD PRES 
Kochhar 101 100 AD_VP 
De Haan 102 100 AD_VP 
Raphaely 114 100 PU_LMAN 
Weiss 120 100 ST_MAN 
Fripp 121 100 ST_MAN 
Kaufling 122 100 ST_ MAN 
Vollman 123 100 ST_ MAN 
Mourgos 124 100 ST_MAN 
Russell 145 100 SA MAN 
Partners 146 100 SA MAN 
Errazuriz 147 100 SA_MAN 
Cambrault 148 100 SA_MAN 
Zlotkey 149 100 SA MAN 
Hartstein 201 100 MK_MAN 


Using Distributed Queries: Example 


This example shows a query that joins the departments table on the local 
database with the employees table on the remote database: 


SELECT last_name, department_name 
FROM employees@remote, departments 
WHERE employees.department_id = departments.department_id; 


Using Correlated Subqueries: Examples 


The following examples show the general syntax of a correlated subquery: 


SELECT select_list 
FROM table! t_alias1 


WHERE expr operator 
(SELECT column_list 
FROM table2 t_alias2 
WHERE t_alias1 . column 
operator t_alias2 . column ); 


UPDATE table1 t_alias1 
SET column = 
(SELECT expr 
FROM table2 t_alias2 
WHERE t_alias1 . column = t_alias2 . column ); 


DELETE FROM table! t_alias1 
WHERE column operator 
(SELECT expr 
FROM table2 t_alias2 
WHERE t_alias1 . column = t_alias2 . column ); 


The following statement returns data about employees whose salaries 
exceed their department average. The following statement assigns an alias 
to employees, the table containing the salary information, and then uses the 
alias in a correlated subquery: 


SELECT department_id, last_name, salary 
FROM employees x 
WHERE salary > (SELECT AVG(salary) 
FROM employees 
WHERE x.department_id = department_id) 
ORDER BY department_id; 


For each row of the employees table, the parent query uses the correlated 
subquery to compute the average salary for members of the same 
department. The correlated subquery performs the following steps for each 
row of the employees table: 


1. The department_id of the row is determined. 


2. The department_id is then used to evaluate the parent query. 


3. If the salary in that row is greater than the average salary of the 
departments of that row, then the row is returned. 


The subquery is evaluated once for each row of the employees table. 
Selecting from the DUAL Table: Example 


The following statement returns the current date: 
SELECT SYSDATE FROM DUAL; 


You could select SYSDATE from the employees table, but the database 
would return 14 rows of the same SYSDATE, one for every row of 
the employees table. Selecting from DUAL is more convenient. 


Selecting Sequence Values: Examples 


The following statement increments the employees_seq sequence and 
returns the new value: 


SELECT employees_seq.nextval 
FROM DUAL; 


The following statement selects the current value of employees_seq: 


SELECT employees_seq.currval 
FROM DUAL; 


Row Pattern Matching: Example 


This example uses row pattern matching to query stock price data. The 
following statements create table Ticker and inserts stock price data into the 
table: 


CREATE TABLE Ticker (SYMBOL VARCHAR2(10), tstamp DATE, 
price NUMBER); 


INSERT INTO Ticker VALUES(‘ACME'’, '01-Apr-11', 12); 
INSERT INTO Ticker VALUES(‘ACME'’, '02-Apr-11', 17); 
INSERT INTO Ticker VALUES(‘ACME'’, '03-Apr-11', 19); 
INSERT INTO Ticker VALUES(‘ACME'’, '04-Apr-11', 21); 
INSERT INTO Ticker VALUES(‘ACME'’, '05-Apr-11', 25); 
INSERT INTO Ticker VALUES(‘ACME'’, '06-Apr-11', 12); 
INSERT INTO Ticker VALUES(‘ACME'’, '07-Apr-11', 15); 
INSERT INTO Ticker VALUES(‘ACME'’, '08-Apr-11', 20); 
INSERT INTO Ticker VALUES(‘ACME'’, '09-Apr-11', 24); 
INSERT INTO Ticker VALUES(‘ACME'’, '10-Apr-11', 25); 
INSERT INTO Ticker VALUES(‘ACME'’, '11-Apr-11', 19); 
INSERT INTO Ticker VALUES(‘ACME'’, '12-Apr-11', 15); 
INSERT INTO Ticker VALUES(‘ACME'’, '13-Apr-11', 25); 
INSERT INTO Ticker VALUES(‘ACME'’, '14-Apr-11', 25); 
INSERT INTO Ticker VALUES(‘ACME'’, '15-Apr-11', 14); 
INSERT INTO Ticker VALUES(‘ACME'’, '16-Apr-11', 12); 
INSERT INTO Ticker VALUES(‘ACME'’, '17-Apr-11', 14); 
INSERT INTO Ticker VALUES(‘ACME'’, '18-Apr-11', 24); 
INSERT INTO Ticker VALUES(‘ACME'’, '19-Apr-11', 23); 
INSERT INTO Ticker VALUES(‘ACME'’, '20-Apr-11', 22); 


The following query uses row pattern matching to find all cases where 
stock prices dipped to a bottom price and then rose. This is generally called 
a V-shape. The resulting output contains only three rows because the query 
specifies ONE ROW PER MATCH, and three matches were found. 


SELECT * 
FROM Ticker MATCH_RECOGNIZE ( 
PARTITION BY symbol 
ORDER BY tstamp 
MEASURES STRI-.tstamp AS start_tstamp, 
LAST(DOWN.tstamp) AS bottom_tstamp, 
LAST(UP.tstamp) AS end_tstamp 
ONE ROW PER MATCH 
AFTER MATCH SKIP TO LAST UP 
PATTERN (STRT DOWN+ UP*+) 


DEFINE 
DOWN AS DOWN. price < PREV(DOWN. price), 
UP AS UP. price > PREV(UP.price) 
) MR 
ORDER BY MR.symbol, MR.start_tstamp; 


SYMBOL START_TST BOTTOM_TS END_TSTAM 


ACME 05-APR-11 06-APR-11 10-APR-11 
ACME 10-APR-11 12-APR-11 13-APR-11 
ACME 14-APR-11 16-APR-11 18-APR-11 


UPDATE 


Use the UPDATE statement to change existing values in a table or in the 
base table of a view or the master table of a materialized view. 


For you to update values in a table, the table must be in your own schema or 
you must have the UPDATE object privilege on the table. 


For you to update values in the base table of a view: 


You must have the UPDATE object privilege on the view, and 


- Whoever owns the schema containing the view must have 
the UPDATE object privilege on the base table. 


The UPDATE ANY TABLE system privilege also allows you to update 
values in any table or in the base table of any view. 


To update values in an object on a remote database, you must also have 
the READ or SELECT object privilege on the object. 


If the SQL92_SECURITY initialization parameter is set to TRUE and 

the UPDATE operation references table columns, such as the columns in a 
where_clause , then you must also have the SELECT object privilege on the 
object you want to update. 


Examples 
Updating a Table: Examples 


The following statement gives null commissions to all employees with the 
job SH_CLERK: 


UPDATE employees 
SET commission_pct = NULL 
WHERE job_id = 'SH_CLERK'; 


The following statement promotes Douglas Grant to manager of 
Department 20 with a $1,000 raise: 


UPDATE employees SET 
job_id = 'SA_MAN’, salary = salary + 1000, department_id = 120 
WHERE first_name||' '||last_name = 'Douglas Grant’; 


The following statement increases the salary of an employee in 
the employees table on the remote database: 


UPDATE employees@remote 
SET salary = salary*1.1 
WHERE last_name = 'Baer'; 


The next example shows the following syntactic constructs of 
the UPDATE statement: 


Both forms of the update_set_clause together in a single statement 
- A correlated subquery 
A where_clause to limit the updated rows 


UPDATE employees a 
SET department_id = 
(SELECT department_id 
FROM departments 
WHERE location_id = '2100'), 
(salary, commission_pct) = 
(SELECT 1.1*AVG(salary), 1.5*AVG(commission_pct) 
FROM employees b 
WHERE a.department_id = b.department_id) 


WHERE department_id IN 
(SELECT department_id 
FROM departments 
WHERE location_id = 2900 
OR location_id = 2700); 


The preceding UPDATE statement performs the following operations: 


Updates only those employees who work in Geneva or Munich 
(locations 2900 and 2700) 


- Sets department_id for these employees to 
the department_id corresponding to Bombay (location_id 2100) 


Sets each employee's salary to 1.1 times the average salary of their 
department 


- Sets each employee's commission to 1.5 times the average 
commission of their department 


Updating a Partition: Example 


The following example updates values in a single partition of 
the sales table: 


UPDATE sales PARTITION (sales_q1_1999) s 
SET s.promo_id = 494 
WHERE amount_sold > 1000; 


Updating an Object Table: Example 


The following statement creates two object 

tables, people_demo1 and people_demo2, of the people_typ object. The 
example shows how to update a row of people _demo1 by selecting a row 
from people_demo2: 


CREATE TABLE people_demo1 OF people_typ; 


CREATE TABLE people_demo2 OF people_typ; 


UPDATE people_demol p SET VALUE(p) = 
(SELECT VALUE(q) FROM people_demo2 q 
WHERE p.department_id = q.department_id) 
WHERE p.department_id = 10; 


The example uses the VALUE object reference function in both 
the SET clause and the subquery. 


Correlated Update: Example 
For an example that uses a correlated subquery to update nested table rows. 
Using the RETURNING Clause During UPDATE: Example 


The following example returns values from the updated row and stores the 
result in PL/SQL variables bnd1, bnd2, bnd3: 


UPDATE employees 
SET job_id ='SA_MAN', salary = salary + 1000, department_id = 
140 
WHERE last_name = ‘Jones' 
RETURNING salary*0.25, last_name, department_id 
INTO :bnd1, :bnd2, :bnd3; 


The following example shows that you can specify a single-set aggregate 
function in the expression of the returning clause: 


UPDATE employees 
SET salary = salary * 1.1 
WHERE department_id = 100 
RETURNING SUM(salary) INTO :bnd1; 


DELETE 


Use the DELETE statement to remove rows from: 


- An unpartitioned or partitioned table 
The unpartitioned or partitioned base table of a view 


The unpartitioned or partitioned container table of a writable 
materialized view 


The unpartitioned or partitioned master table of an updatable 
materialized view 


For you to delete rows from a table, the table must be in your own schema 
or you must have the DELETE object privilege on the table. 


For you to delete rows from an updatable materialized view, the 
materialized view must be in your own schema or you must have 
the DELETE object privilege on the materialized view. 


For you to delete rows from the base table of a view, the owner of the 
schema containing the view must have the DELETE object privilege on the 
base table. Also, if the view is in a schema other than your own, then you 
must have the DELETE object privilege on the view. 


The DELETE ANY TABLE system privilege also allows you to delete rows 
from any table or table partition or from the base table of any view. 


To delete rows from an object on a remote database, you must also have 
the READ or SELECT object privilege on the object. 


If the SQL92_SECURITY initialization parameter is set to TRUE and 

the DELETE operation references table columns, such as the columns in a 
where_clause , then you must also have the SELECT object privilege on the 
object from which you want to delete rows. 


You cannot delete rows from a table if a function-based index on the table 
has become invalid. You must first validate the function-based index. 


Examples 
Deleting Rows: Examples 


The following statement deletes all rows from the sample 
table oe.product_descriptions where the value of the language_id column 
is AR: 


DELETE FROM product_descriptions 
WHERE language_id = 'AR’; 


The following statement deletes from the sample 
table hr.employees purchasing clerks whose commission rate is less than 
10%: 


DELETE FROM employees 
WHERE job_id = 'SA_REP' 
AND commission_pct < .2; 


The following statement has the same effect as the preceding example, but 
uses a subquery: 


DELETE FROM (SELECT * FROM employees) 
WHERE job_id = 'SA_REP' 
AND commission_pct < .2; 


Deleting Rows from a Remote Database: Example 


The following statement deletes specified rows from the locations table 
owned by the user hr on a database accessible by the database link remote: 


DELETE FROM hr.locations@remote 
WHERE location_id > 3000; 


Deleting Nested Table Rows: Example 
For an example that deletes nested table rows. 
Deleting Rows from a Partition: Example 


The following example removes rows from partition sales_qi_1998 of 
the sh.sales table: 


DELETE FROM sales PARTITION (sales_qi_ 1998) 
WHERE amount_sold > 1000; 


Using the RETURNING Clause: Example 


The following example returns column salary from the deleted rows and 
stores the result in bind variable :bnd1. The bind variable must already have 
been declared. 


DELETE FROM employees 
WHERE job_id = 'SA_REP' 
AND hire_date + TO_YMINTERVAL('01-00') < SYSDATE 
RETURNING salary INTO :bnd1; 


Deleting Data from a Table: Example 


The following statements create a table named product_price_history and 
insert data into it: 


CREATE TABLE product_price_history ( 
product_id INTEGER NOT NULL, 
price INTEGER NOT NULL, 
currency_code VARCHAR2(3 CHAR) NOT NULL, 
effective_from_date DATE NOT NULL, 
effective_to_date DATE, 
CONSTRAINT product_price_history_pk 
PRIMARY KEY (product_id, currency_code, effective_from_date) 
) PARTITION BY RANGE (effective_from_date) ( 
PARTITION p0 VALUES less than (DATE'2015-01-02'), 
PARTITION p1 VALUES less than (DATE'2015-01-03'), 
PARTITION p2 VALUES less than (DATE'2015-01-04') 


); 


INSERT INTO product_price_history 
WITH prices AS ( 

SELECT 1, 100, 'USD', DATE'2015-01-01', DATE'2015-01-02' 
FROM dual UNION ALL 

SELECT 1, 60, 'GBP', DATE'2015-01-01', DATE'2015-01-02' 
FROM dual UNION ALL 

SELECT 1, 110, 'EUR', DATE'2015-01-01', DATE'2015-01-02' 
FROM dual UNION ALL 

SELECT 1, 101, 'USD', DATE'2015-01-02', DATE'2015-01-03' 


FROM dual UNION ALL 

SELECT 1, 62, 'GBP', DATE'2015-01-02', DATE'2015-01-03' 
FROM dual UNION ALL 

SELECT 1, 109, 'EUR', DATE'2015-01-02', DATE'2015-01-03' 
FROM dual UNION ALL 

SELECT 1, 105, 'USD', DATE'2015-01-03', NULL 

FROM dual UNION ALL 

SELECT 1, 61, 'GBP', DATE'2015-01-03', NULL 

FROM dual UNION ALL 

SELECT 1, 107, 'EUR', DATE'2015-01-03', NULL 

FROM dual UNION ALL 

SELECT 2, 30, 'USD', DATE'2015-01-01', DATE'2015-01-03' 
FROM dual UNION ALL 

SELECT 2, 33, 'USD', DATE'2015-01-03', NULL 

FROM dual UNION ALL 

SELECT 3, 100, 'GBP', DATE'2015-01-03', NULL 

FROM dual 


) 
SELECT * 
FROM prices; 


The following statement deletes the rows from the table 
product_price_history where product_id is 3: 


DELETE FROM product_price_history WHERE product_id = 3; 


The following procedure deletes the rows from the product_price_history 
where product_id is 2 and effective_to_date is NULL: 


DECLARE 

currency product_price_history.currency_code%TY PE; 
BEGIN 

DELETE product_price_history 

WHERE product_id = 2 

AND effective_to_date IS NULL 

returning currency_code INTO currency; 


dbms_output.Put_line(currency); 
END; 


USD 


The following statement deletes the rows from the table 
product_price_history where currency_code is ‘EUR’: 


DELETE (SELECT * FROM product_price_history) WHERE 
currency_code = 'EUR’; 


The following statement uses a subquery to delete rows from 
product_price_history: 


DELETE product_price_history pp 
WHERE (product_id, currency_code, effective_from_date) 
IN (SELECT product_id, currency_code, Max(effective_from_date) 
FROM product_price_history 
GROUP BY product_id, currency_code); 


The following statement uses partitions to delete rows from 
product_price_history: 


DELETE product_price_history partition (p1); 
The following statement displays the table information: 


SELECT * FROM product_price_history; 


PRODUCT_ID PRICE CUR EFFECTIVE EFFECTIVE 


1 100 USD 01-JAN-15 02-JAN-15 
1 60 GBP 01-JAN-15 02-JAN-15 


The following statement deletes all rows from product_price_history: 
DELETE product_price_history; 


LOCK TABLE 


Use the LOCK TABLE statement to lock one or more tables, table 
partitions, or table subpartitions in a specified mode. This lock manually 
overrides automatic locking and permits or denies access to a table or view 
by other users for the duration of your operation. 


Some forms of locks can be placed on the same table at the same time. 
Other locks allow only one lock for a table. 


A locked table remains locked until you either commit your transaction or 
roll it back, either entirely or to a savepoint before you locked the table. 


A lock never prevents other users from querying the table. A query never 
places a lock on a table. Readers never block writers and writers never 
block readers. 


The table or view must be in your own schema, or you must have 
the LOCK ANY TABLE system privilege, or you must have any object 
privilege (except the READ object privilege) on the table or view. 


Examples 
Locking a Table: Example 


The following statement locks the employees table in exclusive mode but 
does not wait if another user already has locked the table: 


LOCK TABLE employees 
IN EXCLUSIVE MODE 
NOWAIT; 


The following statement locks the remote employees table that is accessible 
through the database link remote: 


LOCK TABLE employees@remote 
IN SHARE MODE; 


MERGE 


Use the MERGE statement to select rows from one or more sources for 
update or insertion into a table or view. You can specify conditions to 
determine whether to update or insert into the target table or view. 


This statement is a convenient way to combine multiple operations. It lets 
you avoid multiple INSERT, UPDATE, and DELETE DML statements. 


MERGE is a deterministic statement. You cannot update the same row of 
the target table multiple times in the same MERGE statement. 


You must have the INSERT and UPDATE object privileges on the target 
table and the READ or SELECT object privilege on the source table. To 

specify the DELETE clause of the merge_update_clause , you must also 
have the DELETE object privilege on the target table. 


Examples 
Merging into a Table: Example 


The following example uses the bonuses table in the sample schema oe with 
a default bonus of 100. It then inserts into the bonuses table all employees 
who made sales, based on the sales_rep_id column of the oe.orders table. 
Finally, the human resources manager decides that employees with a salary 
of $8000 or less should receive a bonus. Those who have not made sales get 
a bonus of 1% of their salary. Those who already made sales get an increase 
in their bonus equal to 1% of their salary. The MERGE statement 
implements these changes in one step: 


CREATE TABLE bonuses (employee_id NUMBER, bonus NUMBER 
DEFAULT 100); 


INSERT INTO bonuses(employee_id) 
(SELECT e.employee_id FROM employees e, orders o 
WHERE e.employee_id = o.sales_rep_id 


GROUP BY e.employee_id); 
SELECT * FROM bonuses ORDER BY employee_id; 


EMPLOYEE ID BONUS 


153 100 

154 100 

155 100 

156 100 

158 100 

159 100 

160 100 

161 100 

163 100 
MERGE INTO bonuses D 

USING (SELECT employee_id, salary, department_id FROM 

employees 


WHERE department_id = 80) S 
ON (D.employee_id = S.employee_id) 
WHEN MATCHED THEN UPDATE SET D.bonus = D.bonus + 
S.salary*.01 
DELETE WHERE (S.salary > 8000) 
WHEN NOT MATCHED THEN INSERT (D.employee_id, 
D.bonus) 
VALUES (S.employee_id, S.salary*.01) 
WHERE (S.salary <= 8000); 


SELECT * FROM bonuses ORDER BY employee_id; 


EMPLOYEE ID BONUS 


153 180 
154 175 
155 170 


160 175 


161 170 
164 72 
165 68 
166 64 
167 62 
171 74 
172 73 
173 61 
179 62 


Conditional Insert and Update: Example 


The following example conditionally inserts and updates table data by using 
the MERGE statement. 


The following statements create two tables 
named people_source and people_target and populate them with names: 


CREATE TABLE people_source ( 
person_id INTEGER NOT NULL PRIMARY KEY, 
first_name VARCHAR2(20) NOT NULL, 
last name VARCHAR2(20) NOT NULL, 

title VARCHAR2(10) NOT NULL 


); 


CREATE TABLE people_target ( 
person_id INTEGER NOT NULL PRIMARY KEY, 
first_name VARCHAR2(20) NOT NULL, 
last name VARCHAR2(20) NOT NULL, 

title VARCHAR2(10) NOT NULL 


); 


INSERT INTO people_target VALUES (1, John’, ‘Smith’, 'Mr'); 
INSERT INTO people_target VALUES (2, ‘alice’, 'jones', 'Mrs'); 
INSERT INTO people_source VALUES (2, 'Alice', ‘Jones’, 'Mrs.'); 
INSERT INTO people_source VALUES (3, ‘Jane’, 'Doe', 'Miss'); 
INSERT INTO people_source VALUES (4, 'Dave', 'Brown'’, 'Mr'); 


COMMIT; 


The following statement compares the contents 

of people_target and people_source by using the person_id column. The 
values in the people_target table are updated when there is a match in 
the people_source table: 


MERGE INTO people_target pt 
USING people_source ps 
ON (pt.person_id = ps.person_id) 
WHEN matched THEN UPDATE 
SET pt.first_name = ps.first_name, 
pt.last_name = ps.last_name, 
pt.title = ps.title; 


The following statements display the contents of the people_target table and 
perform a rollback: 


SELECT * FROM people_target; 


PERSON_ID FIRST_NAME LAST_NAME TITLE 


1 John Smith Mr 
2 Alice Jones Mrs. 


ROLLBACK; 


This statement compares the contents of 

the people_target and people_source tables by using the person_id column. 
The values in the people_target table are updated only when there is no 
match in the people_source table: 


MERGE INTO people_target pt 
USING people_source ps 


ON  (pt.person_id = ps.person_id) 
WHEN NOT matched THEN INSERT 
(pt.person_id, pt.first_name, pt.last_name, pt.title) 
VALUES (ps.person_id, ps.first_name, ps.last_name, ps.title); 


The following statements display the contents of the people_target table and 
perform a rollback: 


SELECT * FROM people_target; 


PERSON_ID FIRST NAME LAST NAME TITLE 
1 John Smith Mr 

2 alice jones Mrs 

3 Jane Doe Miss 

4 Dave Brown Mr 


ROLLBACK; 


The following statement compares the contents of 

the people_target and people_source tables by using the person_id column 
and conditionally inserts and updates data in the people_target table. For 
each matching row in the people_source table, the values in 

the people_target table are updated by using the values from 

the people_source table. Any unmatched rows from the people_source table 
are added to the people_target table: 


MERGE INTO people_target pt 
USING people_source ps 
ON  (pt.person_id = ps.person_id) 
WHEN matched THEN UPDATE 
SET pt.first_name = ps.first_name, 
pt.last_name = ps.last_name, 
pt.title = ps.title 
WHEN NOT matched THEN INSERT 
(pt.person_id, pt.first_name, pt.last_name, pt.title) 


VALUES (ps.person_id, ps.first_name, ps.last_name, ps.title); 


The following statements display the contents of the people_target table and 
perform a rollback: 


SELECT * FROM people_target; 


PERSON_ID FIRST NAME LAST NAME TITLE 
1 John Smith Mr 

2 Alice Jones Mrs. 

3 Jane Doe Miss 

4 Dave Brown Mr 


ROLLBACK; 


The following statement compares 

the people_target and people_source tables by using the person_id column. 
When the person_id matches, the corresponding rows in 

the people_target table are updated by using values from 

the people_source table. The DELETE clause removes all the values 

in people_target where title is ‘Mrs.’. When the person_id does not match, 
the rows from the people_source table are added to the people_target table. 
The WHERE clause ensures that only values that have title as ‘Mr’ are 
added to the people_target table: 


MERGE INTO people_target pt 
USING people_source ps 
ON (pt.person_id = ps.person_id) 
WHEN matched THEN UPDATE 
SET pt.first_name = ps.first_name, 
pt.last_name = ps.last_name, 
pt.title = ps.title 
DELETE where pt.title = 'Mrs.' 
WHEN NOT matched THEN INSERT 
(pt.person_id, pt.first_name, pt.last_name, pt.title) 


VALUES (ps.person_id, ps.first_name, ps.last_name, ps.title) 
WHERE ps.title = 'Mr'; 


The following statements display the contents of the people_target table and 
perform a rollback: 


SELECT * FROM people_target; 


PERSON_ID FIRST_NAME LAST_NAME TITLE 


1 John Smith Mr 
4 Dave Brown Mr 


ROLLBACK; 


Transaction Control Statements 


Transaction control statements manage changes made by DML statements. 
The transaction control statements are: 


> COMMIT 
ROLLBACK 
SAVEPOINT 
SET TRANSACTION 
SET CONSTRAINT 


COMMIT 


Use the COMMIT statement to end your current transaction and make 
permanent all changes performed in the transaction. A transaction is a 
sequence of SQL statements that Oracle Database treats as a single unit. 
This statement also erases all savepoints in the transaction and releases 
transaction locks. 


Until you commit a transaction: 


You can see any changes you have made during the transaction by 
querying the modified tables, but other users cannot see the changes. 
After you commit the transaction, the changes are visible to other 
users’ statements that execute after the commit. 


- You can roll back (undo) any changes made during the transaction 
with the ROLLBACK statement. 


Oracle Database issues an implicit COMMIT before and after any data 
definition language (DDL) statement. 


You can also use this statement to 


- Commit an in-doubt distributed transaction manually 
- Terminate a read-only transaction begun bya SET TRANSACTION 
statement 

Oracle recommends that you explicitly end every transaction in your 
application programs witha COMMIT or ROLLBACK statement, 
including the last transaction, before disconnecting from Oracle Database. 
If you do not explicitly commit the transaction and the program terminates 
abnormally, then the last uncommitted transaction is automatically rolled 
back. 


A normal exit from most Oracle utilities and tools causes the current 
transaction to be committed. A normal exit from an Oracle precompiler 
program does not commit the transaction and relies on Oracle Database to 
roll back the current transaction. 


Examples 
Committing an Insert: Example This statement inserts a row into the 
hr.regions table and commits this change: 


INSERT INTO regions VALUES (5, 'Antarctica’); 


COMMIT WORK; 


To commit the same insert operation and instruct the database to buffer the 
change to the redo log, without initiating disk I/O, use the following 
COMMIT statement: 


COMMIT WRITE BATCH; 


Commenting on COMMIT: Example The following statement commits 
the current transaction and associates a comment with it: 


COMMIT 
COMMENT 'In-doubt transaction Code 36, Call (415) 555-2637’; 


If a network or machine failure prevents this distributed transaction from 
committing properly, then Oracle Database stores the comment in the data 
dictionary along with the transaction ID. The comment indicates the part of 
the application in which the failure occurred and provides information for 
contacting the administrator of the database where the transaction was 
committed. 


Forcing an In-Doubt Transaction: Example The following statement 
manually commits an in-doubt distributed transaction: 


COMMIT FORCE '22.57.53'; 


ROLLBACK 


Use the ROLLBACK statement to undo work done in the current 
transaction or to manually undo the work done by an in-doubt distributed 


transaction. 
To roll back your current transaction, no privileges are necessary. 


To manually roll back an in-doubt distributed transaction that you originally 
committed, you must have the FORCE TRANSACTION system privilege. 
To manually roll back an in-doubt distributed transaction originally 
committed by another user, you must have 

the FORCE ANY TRANSACTION system privilege. 


Examples 
Rolling Back Transactions: Examples 


The following statement rolls back your entire current transaction: 
ROLLBACK; 


The following statement rolls back your current transaction to 
Savepoint banda_sal: 


ROLLBACK TO SAVEPOINT banda_sal; 


The following statement manually rolls back an in-doubt distributed 
transaction: 


ROLLBACK WORK FORCE '25.32.87'; 


SAVEPOINT 


Use the SAVEPOINT statement to create a name for a system change 
number (SCN), to which you can later roll back. 


Examples 
Creating Savepoints: Example 


To update the salary for Banda and Greene in the sample 
table hr.employees, check that the total department salary does not exceed 
314,000, then reenter the salary for Greene: 


UPDATE employees 

SET salary = 7000 

WHERE last_name = ‘Banda’; 
SAVEPOINT banda_sal; 


UPDATE employees 

SET salary = 12000 

WHERE last_name = 'Greene'; 
SAVEPOINT greene_sal; 


SELECT SUM(salary) FROM employees; 
ROLLBACK TO SAVEPOINT banda_sal; 


UPDATE employees 
SET salary = 11000 
WHERE last_name = 'Greene'; 


COMMIT; 


SET TRANSACTION 


Use the SET TRANSACTION statement to establish the current transaction 
as read-only or read/write, establish its isolation level, assign it to a 
specified rollback segment, or assign a name to the transaction. 


A transaction implicitly begins with any operation that obtains a TX lock: 
When a statement that modifies data is issued 
When a SELECT ... FOR UPDATE statement is issued 


- When a transaction is explicitly started with 
a SET TRANSACTION statement or 
the DBMS_TRANSACTION package 


Issuing either a COMMIT or ROLLBACK statement explicitly ends the 
current transaction. 


The operations performed by a SET TRANSACTION statement affect only 
your current transaction, not other users or other transactions. Your 
transaction ends whenever you issue 

a COMMIT or ROLLBACK statement. Oracle Database implicitly commits 
the current transaction before and after executing a data definition language 
(DDL) statement. 


If you use a SET TRANSACTION statement, then it must be the first 
statement in your transaction. However, a transaction need not have 
a SET TRANSACTION statement. 


READ ONLY 


The READ ONLY clause establishes the current transaction as a read-only 
transaction. This clause established transaction-level read consistency . 


All subsequent queries in that transaction see only changes that were 
committed before the transaction began. Read-only transactions are useful 
for reports that run multiple queries against one or more tables while other 
users update these same tables. 


This clause is not supported for the user SYS. Queries by SYS will return 
changes made during the transaction even if SYS has set the transaction to 
be READ ONLY. 


READ WRITE 


Specify READ WRITE to establish the current transaction as a read/write 
transaction. This clause establishes statement-level read consistency , 
which is the default. 


ISOLATION LEVEL Clause 


- The SERIALIZABLE setting specifies serializable transaction 
isolation mode as defined in the SQL standard. If a serializable 
transaction contains data manipulation language (DML) that attempts 
to update any resource that may have been updated in a transaction 
uncommitted at the start of the serializable transaction, then the DML 
statement fails. 


- The READ COMMITTED setting is the default Oracle Database 
transaction behavior. If the transaction contains DML that requires 


row locks held by another transaction, then the DML statement waits 
until the row locks are released. 


USE ROLLBACK SEGMENT Clause 


Specify USE ROLLBACK SEGMENT to assign the current transaction to 
the specified rollback segment. This clause also implicitly establishes the 
transaction as a read/write transaction. 


Parallel DML requires more than one rollback segment. Therefore, if your 
transaction contains parallel DML operations, then the database ignores this 
clause. 


NAME Clause 


Use the NAME clause to assign a name to the current transaction. This 
clause is especially useful in distributed database environments when you 
must identify and resolve in-doubt transactions. The string value is limited 
to 255 bytes. 


If you specify a name for a distributed transaction, then when the 
transaction commits, the name becomes the commit comment, overriding 
any comment specified explicitly in the COMMIT statement. 


Examples 
Setting Transactions: Examples 


The following statements could be run at midnight of the last day of every 
month to count the products and quantities on hand in the Toronto 
warehouse in the sample Order Entry (oe) schema. This report would not be 
affected by any other user who might be adding or removing inventory to a 
different warehouse. 


COMMIT; 
SET TRANSACTION READ ONLY NAME ‘Toronto’; 
SELECT product_id, quantity_on_hand FROM inventories 


WHERE warehouse_id = 5 
ORDER BY product_id; 


COMMIT; 


The first COMMIT statement ensures that SET TRANSACTION is the first 
statement in the transaction. The last COMMIT statement does not actually 
make permanent any changes to the database. It simply ends the read-only 
transaction. 


SET CONSTRAINT[S] 


Use the SET CONSTRAINTS statement to specify, for a particular 
transaction, whether a deferrable constraint is checked following each DML 
statement (IMMEDIATE) or when the transaction is committed 
(DEFERRED). You can use this statement to set the mode for a list of 
constraint names or for ALL constraints. 


The SET CONSTRAINTS mode lasts for the duration of the transaction or 
until another SET CONSTRAINTS statement resets the mode. 


You cannot specify this statement inside of a trigger definition. 


SET CONSTRAINTS can be a distributed statement. Existing database 
links that have transactions in process are notified when 

a SET CONSTRAINTS ALL statement is issued, and new links are notified 
that it was issued as soon as they start a transaction. 


To specify when a deferrable constraint is checked, you must have 
the READ or SELECT privilege on the table to which the constraint is 
applied unless the table is in your schema. 


IMMEDIATE 


Specify IMMEDIATE to cause the specified constraints to be checked 
immediately on execution of each constrained DML statement. Oracle 
Database first checks any constraints that were deferred earlier in the 
transaction and then continues immediately checking constraints of any 
further statements in that transaction, as long as all the checked constraints 
are consistent and no other SET CONSTRAINTS statement is issued. If any 
constraint fails the check, then an error is signaled. At that point, 

a COMMIT statement causes the whole transaction to undo. 


Making constraints immediate at the end of a transaction is a way of 
checking whether COMMIT can succeed. You can avoid unexpected 


rollbacks by setting constraints to IMMEDIATE as the last statement in a 
transaction. If any constraint fails the check, you can then correct the error 
before committing the transaction. 


DEFERRED 


Specify DEFERRED to indicate that the conditions specified by the 
deferrable constraint are checked when the transaction is committed. 


Examples 
Setting Constraints: Examples 


The following statement sets all deferrable constraints in this transaction to 
be checked immediately following each DML statement: 


SET CONSTRAINTS ALL IMMEDIATE; 


The following statement checks three deferred constraints when the 
transaction is committed. This example fails if the constraints were 
specified to be NOT DEFERRABLE. 


SET CONSTRAINTS emp_job_nn, emp_salary_min, 
hr.jhist_dept_fk@remote DEFERRED; 


Session Control Statements 


Session control statements dynamically manage the properties of a user 
session. These statements do not implicitly commit the current transaction. 


PL/SQL does not support session control statements. The session control 
statements are: 


e ALTER SESSION 
SET ROLE 


ALTER SESSION 
Use the ALTER SESSION statement to set or modify any of the 


conditions or parameters that affect your connection to the database. The 
statement stays in effect until you disconnect from the database. 


To enable and disable the SQL trace facility, you must have ALTER 
SESSION system privilege. To enable or disable resumable space 
allocation, you must have the RESUMABLE system privilege. You do not 
need any privileges to perform the other operations of this statement unless 
otherwise indicated. 


Examples 


Enabling Parallel DML: Example Issue the following statement to 
enable parallel DML mode for the current session: 


ALTER SESSION ENABLE PARALLEL DML; 


Forcing a Distributed Transaction: Example The following transaction 
inserts an employee record into the employees table on the database 
identified by the database link remote and deletes an employee record 
from the employees table on the database identified by local : 


ALTER SESSION 
ADVISE COMMIT; 


INSERT INTO employees@remote 
VALUES (8002, ‘Juan’, 'Fernandez’, 'juanf@example.com', NULL, 
TO_DATE(‘04-OCT-1992', 'DD-MON-YYYY’), 'SA_CLERK'’, 3000, 
NULL, 121, 20); 


ALTER SESSION 
ADVISE ROLLBACK; 


DELETE FROM employees@local 
WHERE employee_id = 8002; 


COMMIT; 


This transaction has two ALTER SESSION statements with the 
ADVISE clause. If the transaction becomes in doubt, then remote is sent 
the advice ' COMMIT ' by virtue of the first ALTER SESSION statement 
and local is sent the advice ' ROLLBACK ' by virtue of the second 
statement. 

Closing a Database Link: Example This statement updates the jobs 
table on the local database using a database link, commits the transaction, 
and explicitly closes the database link: 


UPDATE jobs@local SET min_salary = 3000 
WHERE job_id = 'SH_CLERK’; 
COMMIT; 


ALTER SESSION 
CLOSE DATABASE LINK local; 


Changing the Date Format Dynamically: Example The following 
statement dynamically changes the default date format for your session to 
"YYYY MM DD-HH24:MI:SS' : 


ALTER SESSION 
SET NLS_DATE_ FORMAT = "YYYY MM DD HH24:MI:SS'; 


Oracle Database uses the new default date format: 


SELECT TO_CHAR(SYSDATE) Today 
FROM DUAL; 


2001 04 12 12:30:38 


Changing the Date Language Dynamically: Example The following 
statement changes the language for date format elements to French: 


ALTER SESSION 
SET NLS_DATE_LANGUAGE = French; 


SELECT TO_CHAR(SYSDATE, 'Day DD Month YYYY') Today 
FROM DUAL; 


Jeudi 12 Avril 2001 


Changing the ISO Currency: Example The following statement 
dynamically changes the ISO currency symbol to the ISO currency symbol 
for the territory America: 


ALTER SESSION 
SET NLS_ISO_CURRENCY = America; 


SELECT TO_CHAR( SUM(salary), 'C999G999D99') Total 
FROM employees; 


USD694,900.00 


Changing the Decimal Character and Group Separator: Example The 
following statement dynamically changes the decimal character to comma 
(,) and the group separator to period (.): 


ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ',.'; 


Oracle Database returns these new characters when you use their number 
format elements: 


ALTER SESSION SET NLS_CURRENCY ='FF'; 


SELECT TO_CHAR( SUM(salary), 'L999G999D99') Total FROM 
employees; 


FF694.900,00 


Changing the NLS Currency: Example The following statement 
dynamically changes the local currency symbol to ' DM ': 


ALTER SESSION 
SET NLS_CURRENCY = 'DM'; 


SELECT TO_CHAR( SUM(salary), 'L999G999D99') Total 
FROM employees; 


DM694.900,00 


Changing the NLS Language: Example The following statement 
dynamically changes to French the language in which error messages are 
displayed: 


ALTER SESSION 
SET NLS_LANGUAGE = FRENCH; 


Session modifiee. 
SELECT * FROM DMP; 


ORA-00942: Table ou vue inexistante 


Changing the Linguistic Sort Sequence: Example The following 
statement dynamically changes the linguistic sort sequence to Spanish: 


ALTER SESSION 
SET NLS_SORT = XSpanish; 


Oracle Database sorts character values based on their position in the 
Spanish linguistic sort sequence. 

Enabling SQL Trace: Example To enable the SQL trace facility for your 
session, issue the following statement: 


ALTER SESSION 
SET SQL_TRACE = TRUE; 


Enabling Query Rewrite: Example This statement enables query rewrite 
in the current session for all materialized views that have not been explicitly 
disabled: 


ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE; 


SET ROLE 


When a user logs on to Oracle Database, the database enables all privileges 
granted explicitly to the user and all privileges in the user's default roles. 
During the session, the user or an application can use 

the SET ROLE statement any number of times to enable or disable the roles 
currently enabled for the session. 


You cannot enable more than 148 user-defined roles at one time. 


You can see which roles are currently enabled by examining 
the SESSION_ROLES data dictionary view. You must already have been 
granted the roles that you name in the SET ROLE statement. 


ALL Clause 


Specify ALL to enable all roles granted to you for the current session except 
those optionally listed in the EXCEPT clause. 


Roles listed in the EXCEPT clause must be roles granted directly to you. 
They cannot be roles granted to you through other roles. 


If you list a role in the EXCEPT clause that has been granted to you both 
directly and through another role, then the role remains enabled by virtue of 
the role to which it has been granted. 


NONE 


Specify NONE to disable all roles for the current session, including 
the DEFAULT role. 


Examples 
Setting Roles: Examples 


To enable the role dw_manager identified by the password warehouse for 
your current session, issue the following statement: 


SET ROLE dw_manager IDENTIFIED BY warehouse; 


To enable all roles granted to you for the current session, issue the 
following statement: 


SET ROLE ALL; 


To enable all roles granted to you except dw_manager, issue the following 
statement: 


SET ROLE ALL EXCEPT dw_manager; 


To disable all roles granted to you for the current session, issue the 
following statement: 


SET ROLE NONE; 


Using XML in SQL Statements 


This section describes some of the ways you can use XMLType data in the 
database. 


XMLtType Tables 


The sample schema oe contains a table warehouses, which contains 

an XMLType column warehouse_spec. Suppose you want to create a 
separate table with the warehouse_spec information. The following 
example creates a very simple XMLType table with one CLOB column: 


CREATE TABLE xwarehouses OF XMLTYPE 
XMLTYPE STORE AS CLOB; 


You can insert into such a table using XMLType syntax, as shown in the 
next statement. (The data inserted in this example corresponds to the data in 
the warehouse_spec column of the sample 

table oe.warehouses where warehouse_id = 1.) 


INSERT INTO xwarehouses VALUES 
(xmltype(‘<?xml version="1.0"?> 
<Warehouse> 

<Warehouseld>1</Warehouseld> 
<WarehouseName>Southlake, Texas</WarehouseName> 
<Building>Owned</Building> 
<Area>25000</Area> 
<Docks>2</Docks> 
<DockType>Rear load</DockType> 
<WaterAccess>true</WaterAccess> 
<RailAccess>N</RailAccess> 
<Parking>Street</Parking> 
<VClearance>10</VClearance> 
</Warehouse>')); 


You can query this table with the following statement: 


SELECT e.getClobVal() FROM xwarehouses e; 


CLOB columns are subject to all of the restrictions on LOB columns. To 
avoid these restrictions, create an XMLSchema-based table. The 
XMLSchema maps the XML elements to their object-relational equivalents. 
The following example registers an XMLSchema locally. The XMLSchema 
(xwarhouses.xsd) reflects the same structure as the xwarehouses table. 
(XMLSchema declarations use PL/SQL and 

the DBMS_XMLSCHEMA package, so the example is shown in italics.) 


begin 
dbms_xmlschema.registerSchema( 

‘http://www.example.com/xwarehouses.xsd', 

'<schema xmlns="http://www.w3.org/2001/X MLSchema" 
targetNamespace= "http://www.example.com/xwarehouses.xsd" 
xmIns:who="http://www.example.com/xwarehouses.xsd" 
version="1.0"> 


<simpleType name="RentalType"> 
<restriction base="string"> 
<enumeration value="Rented"/> 
<enumeration value="Owned"/> 
</restriction> 

</simpleType> 


<simpleType name="ParkingType"> 
<restriction base="string"> 
<enumeration value="Street"/> 
<enumeration value= "Lot"/> 
</restriction> 

</simpleType> 


<element name = "Warehouse"> 
<complexType> 
<sequence> 


<element name = "Warehouseld" type = "positiveInteger"/> 
<element name = "WarehouseName" type = "string"/> 
<element name = "Building" type = "who:RentalType"/> 


<element name = "Area" type = "positiveInteger"/> 
<element name = "Docks" type = "positiveInteger"/> 
<element name = "DockType" type = "Sstring"/> 


<element name = "WaterAccess" type = "boolean"/> 
<element name = "RailAccess" type = "boolean"/> 
<element name = "Parking" type = "who:ParkingType"/> 
<element name = "VClearance" type = "positiveInteger"/> 
</sequence> 
</complexType> 
</element> 
</schema>', 
TRUE, TRUE, FALSE, FALSE); 
end; 
/ 


Now you can create an XMLSchema-based table, as shown in the following 
example: 


CREATE TABLE xwarehouses OF XMLTYPE 
XMLSCHEMA "http://www.example.com/xwarehouses.xsd" 
ELEMENT "Warehouse"; 


By default, Oracle stores this as an object-relational table. Therefore, you 
can insert into it as shown in the example that follows. (The data inserted in 
this example corresponds to the data in the warehouse_spec column of the 
sample table oe.warehouses where warehouse_id = 1.) 


INSERT INTO xwarehouses VALUES( xmltype.createxml('<?xml 
version="1.0"?> 
<who: Warehouse 
xmlIns:who="http://www.example.com/xwarehouses.xsd" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.example.com/xwarehouses.xsd 


http://www.example.com/xwarehouses.xsd"> 
<Warehouseld>1</Warehouseld> 
<WarehouseName>Southlake, Texas</WarehouseName> 
<Building>Owned</Building> 
<Area>25000</Area> 
<Docks>2</Docks> 
<DockType>Rear load</DockType> 
<WaterAccess>true</WaterAccess> 
<RailAccess>false</RailAccess> 
<Parking>Street</Parking> 
<VClearance>10</VClearance> 
</who:Warehouse>')); 


You can define constraints on an XMLSchema-based table. To do so, you 
use the XMLDATA pseudocolumn to refer to the appropriate attribute 
within the Warehouse XML element: 


ALTER TABLE xwarehouses ADD (PRIMARY 
KEY(XMLDATA."Warehouseld")); 


Because the data in xwarehouses is stored object relationally, Oracle 
rewrites queries to this XMLType table to go to the underlying storage 
when possible. Therefore the following queries would use the index created 
by the primary key constraint in the preceding example: 


SELECT * FROM xwarehouses x 
WHERE EXISTSNODE(VALUE(x), 

'/Warehouse| Warehouseld="1"]', 
‘xmlins:who="http://www.example.com/xwarehouses.xsd"") = 1; 


SELECT * FROM xwarehouses x 
WHERE EXTRACTVALUE(VALUE(x), 
'/Warehouse/Warehouseld', 
‘xmlins:who="http://www.example.com/xwarehouses.xsd"") = 1; 


You can also explicitly create indexes on XMLSchema-based tables, which 
greatly enhance the performance of subsequent queries. You can create 
object-relational views on XMLType tables, and you can 

create XMLType views on object-relational tables. 


XMLType Columns 


The sample table oe.warehouses was created with 

a warehouse_spec column of type XMLType. The examples in this section 
create a shortened form of the oe.warehouses table, using two different 
types of storage. 


The first example creates a table with an XMLType table stored as a CLOB. 
This table does not require an XMLSchema, so the content structure is not 
predetermined: 


CREATE TABLE xwarehouses ( 
warehouse_id NUMBER, 
warehouse_spec XMLTYPE) 
XMLTYPE warehouse_spec STORE AS CLOB 
(TABLESPACE example 
STORAGE (INITIAL 6144) 
CHUNK 4000 
NOCACHE LOGGING); 


The following example creates a similar table, but stores the XMLType data 
in an object-relational XMLType column whose structure is determined by 
the specified XMLSchema: 


CREATE TABLE xwarehouses ( 
warehouse_id NUMBER, 
warehouse_spec XMLTYPE) 
XMLTYPE warehouse_spec STORE AS OBJECT RELATIONAL 
XMLSCHEMA "http://www.example.com/xwarehouses.xsd" 
ELEMENT "Warehouse"; 


